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Preface 


The  purpose  of  this  thesis  was  to  develop  a  simulation  model  of  a 
token-passing  bus  local  area  network.  The  Intended  application  of  the 
simulated  networks  Is  that  of  the  specialized  aircraft  avionics  data  bus 
network.  The  simulation  model  was  successfully  developed  and  validated. 
Initial  testing  was  completed  for  one  protocol  and  a  comparison  test  of 
two  protocols  was  accomplished. 

This  simulation  model  Is  one  of  many  models  and  tools  that  will  be 
needed  to  design  and  develop  a  new  avionics  data  bus  required  for  the 
next  generation  of  aircraft  and  their  complex  avionics. 
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Abstract 


There  are  many  factors  of  bus  token-passing  protocols  that 
influence  the  overall  performance  of  the  protocol.  Extensive  analysis 
is  needed  to  design  a  protocol  with  performance  that  can  meet  the 
requirements  for  a  next-generation  aviation  electronics  (avionics)  data 
bus.  The  purpose  of  this  thesis  was  to  develop  and  test  a  token-passing 
bus^slmulatlon  model  that  could  be  used  to  conduct  this  analysis. 

This  thesis  developed  and  validated  a  model  for  simulating  bus 
token-passing  protocols  for  avionics  applications.  Two  algorithms  were 
designed  that  reflected  the  timing  and  operation  of  a  distributed 
control  token-passing  protocol  and  a  centralized  control  token-passing 
protocol.  The  algorithms  were  incorporated  into  an  overall  simulation 
model  program  which  included  simulation  control,  data  collection,  and 
data  analysis  functions.  The  simulation  model  program  was  written  in 
the  Pascal  computer  programming  language.  »  '  '  > 

The  simulation  model  program  allows  various  avionics  bus 
configurations  to  be  defined  and  tested.  A  series  of  tests  were 
conducted  using  the  simulation  model  program  to  validate  its  operation 
and  modeling  capabilities.  The  validation  tests  were  successful. 

Initial  performance  tests  were  conducted  for  a  centralized  control 
token-passing  protocol  using  a  bus  configuration  representative  of  a 
fighter-type  aircraft  bus  network.  The  performance  of  the  two  types  of 
protocols  was  also  compared. 


SIMULATION  MODEL  OF  A  HIGH-SPEED  TOKEN-PASSING 


BUS  FOR  AVIONICS  APPLICATIONS 


I.  Introduction 

There  Is  presently  a  great  deal  of  Interest  concerning  the  rapidly 
evolving  field  of  local  area  computer  communication  networks,  commonly 
called  local  area  networks  (Myers,  1982:28;  Stallings,  1984a:3).  The 
main  reason  for  this  Interest  In  local  area  networks  (LANs)  stems  from 
the  ability  of  the  local  area  network  to  Interconnect  computer-based 
equipment  so  that  expensive  resources  can  be  shared  and  data  can  be 
exchanged  among  the  equipment  (Stallings,  1984a:3).  Local  area  networks 
are  used  In  aviation  electronics  (avionics)  applications  primarily  to 
reduce  Integration  complexity  and  risk  (Alber  and  Thomas,  1985:130). 

This  introductory  chapter  begins  with  a  background  of  avionics  local 
area  networks  and  reasons  why  a  new  avionics  local  area  network  is 
needed.  Next,  a  brief  description  of  the  problem  Is  given  followed  by  a 
statement  o'"  he  objective  of  this  thesis.  A  summary  of  the  current 
knowledge  concerning  bus  local  area  networks  Is  then  presented  followed 
by  the  approach  taken  In  this  thesis.  The  chapter  concludes  with  an 
overview  of  the  rest  of  the  chapters  and  appendices  of  this  thesis. 

Background 

In  the  late  1960s,  it  became  apparent  that  avionics  integration  by 
use  of  dedicated  hard-wired  interfaces  was  too  costly  and  complex,  and 
led  to  inflexible  avionics  systems  (Gifford,  1974:85).  Therefore,  the 
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concept  of  a  standard  interface  which  would  allow  different  avionic 
equipment  to  exchange  information  via  a  shared  serial  communications 
link  was  developed  (Boeing,  1980:2-2).  Such  a  standard  interface  was 
defined  and  adopted  by  the  Air  Force  as  MIL-STD-1553.  This  standard 
defines  the  hardware  and  protocol  for  a  serial  digital  data  bus  that  is 
shared  by  the  avionics  connected  to  it.  A  time  division  multiplexing 
scheme  is  used  to  allow  the  avionic  equipment  to  share  the  bus  in  a 
controlled  manner.  This  Air  Force  standard  was  later  adopted  by  the 
Department  of  Defense  for  use  by  all  the  military  services. 

As  the  next  generation  of  military  aircraft  is  starting  to  be 
designed,  a  new  standard  Interface  implemented  by  an  avionics  local  area 
network  is  required.  This  new  avionics  network  is  needed  to  meet  the 
Increased  information  flow  requirements  of  the  more  advanced  and  complex 
digital  avionics  that  will  be  used  in  these  aircraft  (Ludvigson  and 
Milton,  1985:122).  Also,  a  broader  range  of  avionic  equipment  could 
take  advantage  of  reductions  in  weight,  integration  complexity  and  cost 
that  avionics  local  area  networks  offer  if  their  information  flow 
requirements  could  be  met  by  such  a  network. 

Problem 

The  US  Air  Force's  Aeronautical  Systems  Division  engineering 
community  has  agreed  on  the  framework  for  a  new  avionics  local  area 
network.  The  use  of  a  token-passing  protocol  with  a  bus  topology  is  the 
preferred  method  (Ludvigson  and  Milton,  1985:123).  However,  there  are 
many  factors  of  the  token-passing  protocol  which  could  influence  the 
performance  of  the  avionics  network,  specifically  the  data  throughput 


rate  and  message  delays.  These  factors  include  bit  rate,  number  of  data 
words  per  message,  maximum  message  size,  number  of  overhead  bits,  size 
of  the  token,  maximum  token-passing  time,  centralized  versus  distributed 
token  scheduling  and  control,  physical  length  of  the  bus,  and  the 
maximum  number  of  terminals  connected  to  the  bus.  Extensive  analysis  Is 
needed  to  determine  what  effect  these  different  factors  have  on  the  data 
throughput  rate  and  message  delays. 

Objective 

The  objective  of  this  thesis  Is  to  design  and  test  a  software 
simulation  model  that  will  allow  analysis  of  the  effect  the  factors 
listed  above  have  on  the  bus's  throughput  rates  and  message  delays. 

This  model  will  aid  In  the  development  of  a  finalized  configuration  for 
the  new  avionics  local  area  network.  The  software  model  will  allow 
simulation  of  the  bus  network  on  a  digital  computer. 


Current  Knowledge 

Due  to  the  popularity  and  Interest  in  local  area  networks,  there 

has  been  a  great  amount  of  work  reported  in  the  literature  concerning 

local  area  networks.  Studies  of  the  token-passing  bus  protocol  found 

pertinent  for  this  thesis  Include  the  following. 

Stallings  discusses  the  factors  that  determine  performance  for 
local  area  networks  Including  token-passing  bus  protocols  and 
develops  simple  performance  equations  (Stallings,  1984b). 

Ulug  compares  the  performance  of  a  token-passing  bus  protocol 
with  different  token-holding  limit  strategies  using  analytical 
and  simulation  methods  (Ulug,  1984). 

Cherukurl  et  ^  evaluate  the  performance  of  a  token-passing 
protocol  for  ring,  baseband  bus,  and  broadband  bus  topologies 
using  analytical  methods  (Cherukurl  e^  a^,  1982). 


Stuck  presents  a  performance  comparison  of  the  popular  media 
access  methods  Including  the  token-passing  bus  protocol  using 
analytical  methods  (Stuck,  1983a). 

Rahlml  and  Jelatls  validate  the  IEEE  802.4  token-passing 
protocol  and  evaluate  Its  performance  by  using  simulation 
methods  (Rahlml  and  Jelatls,  1983). 

Based  upon  the  results  of  these  analytical  and  simulation  studies, 

some  Ideas  concerning  the  performance  of  token-passing  buses  are 

generally  accepted.  These  Ideas  Include  the  following: 

Low  throughput  when  the  bus  Is  lightly  loaded  because  much  of 
the  bandwidth  Is  wasted  passing  the  token  through  Idle 
stations  (Rahlml  and  Jelatls,  1983:801;  Cherukurl  et  al, 
1982:59). 

High  and  stable  throughput  when  the  bus  Is  heavily  loaded 
because  the  overhead  Is  small  compared  to  the  amount  of  data 
being  transferred  (Cherukurl  e£  al.  1982:59). 

Decrease  in  throughput  when  either  the  header  bits  in  the 
message  and/or  the  token  are  increased  in  size  because  both 
are  considered  overhead.  When  they  are  Increased,  more  time 
Is  being  spent  carrying  the  overhead  bits  and  not  data 
(Stallings,  1984b:30). 

Performance  is  sensitive  to  the  message  and  token  propagation 
delays  and  hence  the  length  of  the  bus  (Stuck,  1983a:75-76). 

While  there  has  been  a  great  deal  of  work  involving  analytical  and 
simulation  studies  of  local  area  networks,  most  works  are  not  completely 
applicable  to  the  very  specialized  avionics  application.  Avionics  local 
area  networks  are  different  from  other  typical  local  area  networks  for 
an  office  or  distributed  computing  environment  in  two  main  areas.  The 
first  difference  Is  that  an  avionics  network  has  known  minimum  and 
maximum  station  populations  (Alber,  1985).  The  other  difference  Is  that 
more  Is  known  about  the  message  size  and  arrival  characteristics  for  the 
avionics  network  compared  to  the  other  environments. 


There  are  also  disadvantages  involved  with  the  analytical  method 
Itself.  The  major  drawback  Is  the  simplifying  assumptions  that  must  be 
made  in  order  for  the  analysis  to  be  workable.  These  assumptions  limit 
the  analysis’  value  for  detailed  performance  evaluations  (Rahlml  and 
Jelatis,  1983:801). 

The  problem  with  simulation  studies  Is  the  applicability  of  the 
model.  The  simulation  might  work  correctly,  but  If  the  model  Is  not  an 
accurate  representation  of  the  system  under  study,  the  usefulness  of  the 
simulation  Is  doubtful.  For  example.  Stuck  noted  that  simulation 
studies  for  bus  local  area  networks  did  not  model  the  separation  of  the 
stations  on  the  bus  (Stuck,  1983b:112).  He  found  that  the  simulations 
assumed  worst  case  propagation  delays  for  signals  traveling  between 
stations.  Since  then,  a  bus  local  area  network  simulation  has 
Incorporated  actual  separation  delays;  but  the  study  was  conducted  for 
the  carrier  sense,  multiple  access  with  collision  detection  media  access 
method  as  Implemented  by  Ethernet  (Jackman  and  Medeiros,  1984:595). 


Approach 

The  approach  taken  In  this  thesis  In  developing  a  simulation  model 
of  an  avionics  bus  local  area  network  was  to  develop  an  algorithm  that 
reflected  the  timing  and  protocol  operation  of  a  token-passing  bus 
network.  An  overall  design  was  done  for  the  simulation  model  which 
Incorporated  the  algorithm  and  necessary  simulation  control,  data 
collecting,  and  data  analysis  functions  to  produce  a  complete  simulation 
software  package.  The  package  was  written  In  the  Pascal  programming 
language.  The  simulation  model  allows  various  avionics  bus 
configurations  to  be  set  up  and  tested  so  the  effect  of  the  different 


bus  design  factors  can  be  analyzed.  The  design  factors  that  are 
adjustable  are  listed  below  In  general  categories: 


bus  environment 
bit  rate 

number  of  stations 

length  of  bus 

signal  propagation  speed 

stations 

separation 

token-passing  order 

message  arrival  types  and  rates 

message  length  distribution  types  and  means 

messages 

number  of  overhead  bits 

number  of  bits  In  token 

number  of  bits  In  a  data  word 

minimum  and  maximum  number  of  data  words 

protocol 

centralized  or  distributed  control 
token  holding  time 
station  delay  time 

Besides  setting  up  the  bus  environment  to  be  tested,  the  simulation 

control  function  allows  control  of  the  length  of  the  simulation  run. 

The  data  collecting  function  of  the  simulation  model  program 

collects  data  so  that  the  following  performance  parameters  can  be 

determined  by  the  data  analysis  function: 

data  throughput  rates 
message  delays 
access  delays 
message  size  statistics 
bus  efficiency 


Overview  of  Remaining  Chapters 

Chapter  II  presents  a  brief  overview  and  analysis  of  local  area 
network  topology,  media  access  methods  for  bus  topologies,  and  potential 
protocols  for  the  new  avionics  bus  network.  Chapter  III  discusses  the 


simulation  model.  Chapter  IV  describes  how  the  simulation  model  was 
validated  and  presents  results  from  simulation  runs.  Chapter  V  Is  the 
summary  of  this  thesis  and  presents  some  recommendations.  Appendix  A  Is 
the  simulation  model  users  guide  and  Appendix  B  contains  the  simulation 
model  software.  Appendix  C  contains  the  data  files  used  for  simulation 


II .  Local  Area  Networks 


This  chapter  presents  a  discussion  of  local  area  networks  Including 
topologies  and  bus  media  access  methods.  After  each  topic,  an  analysis 
Is  conducted  that  describes  the  strong  and  weak  points  of  each  topology 
and  access  method  presented.  Four  popular  token-passing  protocols  are 
then  discussed  and  analyzed.  Based  upon  these  analyses,  a  topology, 
media  access  method,  and  protocol  are  selected  for  use  In  this  thesis. 

Definition 

A  local  area  network  can  be  defined  as  “a  communications  network 
that  provides  Interconnection  of  a  variety  of  data  communicating  devices 
within  a  small  area"  (Stallings,  1984a:4). 

Avionics  systems  consist  of  various  equipment  that  depend  on  each 
other  for  basic  Information  concerning  the  aircraft  and  its  environment 
(Boeing,  1980:2-2).  The  avionics  need  to  exchange  this  Information  with 
one  another  In  order  for  each  to  perform  their  function.  An  example  of 
this  Information  exchange  would  be  a  central  air  data  computer  providing 
pressure  altitude  and  air  speed  data  to  an  Inertial  navigation  unit 
(Boeing,  1982:6-5).  Also,  the  avionics  system  is  limited  to  the 
physical  size  of  the  aircraft.  Thus,  an  avionics  bus  system  which 
allows  Information  transfer  agrees  with  the  above  definition  and  is  one 
example  of  many  systems  that  can  be  described  as  a  local  area  network. 

Topology 

There  are  three  main  topologies  that  can  be  used  to  describe  a 
local  area  network:  the  star,  ring  and  tree  topologies  (Stallings, 


1984a: 6).  These  topologies  are  shown  In  Figure  1  where  the  square  boxes 
represent  nodes  or  stations.  The  star  topology  has  a  central  node 
connected  to  all  the  other  nodes  In  the  network.  The  ring  has  each  node 
connected  to  exactly  two  other  nodes  using  point  to  point  connections 
which  form  a  physical  ring.  The  tree  topology  has  a  trunk  with  multiple 
branches.  The  nodes  can  be  located  anywhere  along  the  trunk  and 
branches.  The  special  case  of  a  tree  with  only  a  trunk  Is  called  a  bus 
topology  (Stallings,  1984a:6). 


Topology  Analysis 

The  star  topology  leads  to  the  central  node  becoming  the  bottleneck 
of  the  network  since  all  messages  are  routed  to  or  through  It.  The  ring 
topology  requires  each  node  to  actively  repeat  each  message  to  the  next 
node  on  the  ring.  Also,  If  one  node  falls,  the  ring  Is  broken  unless 
active  bypass  circuits  are  available.  A  break  In  the  media  can  cause  a 
single  point  failure  of  the  bus  topology.  This  failure  mode  can  be 
avoided  If  multiple  buses  are  used. 

Chosen  Topology.  The  bus  was  selected  as  the  preferred  topology 
for  the  new  avionics  local  area  network  for  the  following  reasons:  (1) 
previous  bus  experience  with  MIL-STD-1553,  (2)  nodes  can  be  connected  to 
the  bus  with  passive  connections,  (3)  adding  or  deleting  nodes  Is  easily 
accomplished,  and  (4)  multiple  buses  can  be  used  for  reliability.  One 
reason  for  not  choosing  the  star  topology  was  the  congestion  problem  at 
the  central  node.  Another  reason  was  the  central  node  Is  a  single  point 
of  failure  which  would  cause  the  entire  network  to  fall.  The  ring 
topology  was  not  chosen  because  there  Is  a  chance  that  a  single  failure 
could  break  the  ring.  Active  bypass  circuitry  can  be  used  to  pass  the 


signals  around  the  break,  but  the  bypass  circuitry  adds  another  failure 
mode. 

Bus  Media 

The  media  used  for  the  actual  physical  bus  can  be  a  radio  channel, 
a  coaxial  cable,  a  fiber  optic  cable,  or  a  twlsted-shlelded  pair  of 
wires.  This  thesis  will  not  address  the  choice  of  media  in  keeping  with 
the  current  trend  to  design  media  independent  protocols. 

Media  Access  Methods 

Since  all  the  nodes  in  the  bus  topology  share  a  common 
communications  link  (the  bus),  the  network  requires  a  scheme  for 
controlling  the  nodes'  access  of  the  bus.  This  is  necessary  because 
only  one  message  can  be  successfully  transmitted  and  received  on  the  bus 
at  a  time  (Kurose  ^  al,  1984:44).  This  control  is  called  the  media, 
medium,  channel  or  multiple  access  method  and  is  one  of  the  most 
Important  aspects  of  the  bus  topology.  Also,  due  to  the  shared  bus,  all 
nodes  can  hear  all  messages  transmitted.  This  characteristic  is  called 
broadcast  (Stallings,  1984a:6).  The  media  access  methods  can  be  grouped 
into  three  major  categories:  fixed,  random  or  contention,  and  demand 
assignment  methods  (Liu  at  al,  1982:417). 

Fixed  Assignment  Method.  In  the  fixed  assignment  access  method, 
all  nodes  on  the  bus  are  given  a  certain  amount  of  time  or  frequency  to 
transmit  messages  even  if  they  have  none  to  send.  Examples  of  fixed 
assignment  methods  are  time  division  multiplexing  and  frequency  division 
multiplexing. 


Random  Assignment  Method.  Random  access  methods  try  to  Improve  on 
the  Inefficiency  of  the  fixed  methods  by  only  allowing  nodes  with 
messages  to  randomly  try  and  transmit  them.  However,  there  is  no 
coordination  between  nodes;  so  two  or  more  nodes  can  transmit  at  the 
same  time,  causing  their  messages  to  collide  and  become  useless.  When  a 
collision  occurs,  the  whole  process  is  repeated  until  all  the  messages 
are  successfully  transmitted  (Kurose  et  al.  1984:46).  There  are  various 
versions  of  the  random  access  methods  which  try  and  minimize  this  loss 
of  capacity  due  to  collisions.  Two  familiar  examples  of  random  access 
methods  are  the  various  Aloha  type  methods,  and  the  carrier  sense, 
multiple  access  with  collision  detection  (CSMA/CD)  method  as  Implemented 
by  Ethernet  (Tanenbaum,  1981:253,292). 

Demand  Assignment  Method.  The  demand  access  methods  either 
explicitly  or  implicitly  exchange  control  information  so  at  any  time 
only  one  node  is  in  control  of  the  bus  and  allowed  to  transmit  a 
message.  This  method  avoids  the  problems  associated  with  collisions 
(Kurose  e^  al,  1984:45).  Also,  although  each  node  is  given  the  chance 
to  transmit,  they  do  not  have  to  (IEEE  802.4,  1982:1-10).  This  way,  the 
media  bandwidth  is  not  wasted  by  assigning  it  to  idle  nodes  (Liu  £t  al. 
1982:419).  Examples  of  demand  access  methods  are  the  various  token- 
passing  and  reservation  schemes. 

Media  Access  Method  Analysis 

The  token-passing  method  is  preferred  for  the  new  avionics  bus 
local  area  network  rather  than  other  methods  due  to  its  attractive 


features  for  the  aircraft  avionics  real-time  environment  application 
(Ludvigson  and  Milton,  1985:123).  The  fixed  assignment  access  methods 


are  not  efficient  for  changing  traffic  loads.  The  message  collision 
characteristic  of  the  random  access  method  Is  Inefficient;  and  depending 


on  the  message  transmission  retry  policy,  can  lead  to  non-determlnlstlc 
bus  access  delays.  This  Is  especially  true  under  heavy  traffic  loads. 
The  attractive  features  of  the  token-passing  access  method  Include 
deterministic  access  delays;  no  minimum  packet  length  requirement;  good 
performance  under  heavy  traffic  loads;  fairness  to  all  nodes;  no 
specialized  listening  while  talking  or  collision  detection  circuitry; 
allowing  Implementation  of  multiple  classes  of  service  (priority);  and 
easy  addition  or  deletion  of  nodes  (Stallings,  1984a:28;  Miller  and 
Thompson,  1982:84;  IEEE  802.4,  1982:1-2). 

Token-Passing  Media  Access  Method 

The  token-passing  method  operates  by  having  the  nodes  pass  a 
special  bit  pattern  message  (the  token)  among  themselves.  The  node 
having  the  token  has  control  of  the  bus  and  can  transmit  any  messages  It 
might  have  until  it  has  no  more  messages  or  the  maximum  token-holding 
time  has  expired  (Miller  and  Thompson,  1982:80).  The  token  is  then 
passed  to  the  next  node.  Every  node  Is  guaranteed  a  maximum  time  that 
It  must  wait  between  token  possessions,  which  Is  called  the  maximum 
access  delay  time.  This  access  delay  time  varies  with  the  amount  of 
load  (nodes  with  messages)  on  the  bus.  A  feature  of  this  method  Is  that 
it  places  minimal  restrictions  on  how  a  node  uses  its  bus  time.  This 
allows  a  node  to  use  some  other  access  method  during  Its  bus  control 
time  such  as  poll/response  or  requesting  an  acknowledgement,  as  long  as 
it  does  not  confuse  the  other  nodes  (IEEE  802.4,  1982:1-10). 


data  to 
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Figure  2.  Simple  Token-Passing  Protocol  Simulation 


The  normal  steady-state  operation  of  the  token-passing  protocol  can 
be  thought  of  as  alternating  data  transfer  and  token  transfer  phases 
(Stallings,  1984b:26).  Figure  2  Is  a  simplified  flow  chart 
representation  of  how  this  steady-state  operation  Is  simulated  In  this 
thesis.  The  Figure  starts  with  a  station  having  Just  received  the 
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Figure  3.  Typical  Message  Format 


Messages.  In  addition  to  carrying  actual  data  from  one  station  to 
another,  a  message  in  the  token-passing  media  access  method  also  carries 
information  that  is  necessary  for  the  correct  operation  of  the  token- 
passing  method  (Ludvlgson  and  Milton,  1985:127).  This  information,  such 
as  synchronization,  address,  and  error  control  information,  is  not 
actual  data  that  is  being  transferred  from  one  station  to  another  and 
therefore  is  considered  overhead. 

Message  Format.  The  format  of  a  typical  message  is  shown  in  Figure 
3.  The  preamble  or  synchronization  bits  allow  a  receiving  station  to 
synchronize  Itself  with  the  bus  signal  (Ludvlgson  and  Milton,  1985:127). 
The  start  delimiter  bits  labeled  Start  in  Figure  3  and  the  end  delimiter 
bits  labeled  End  in  Figure  3  are  used  to  define  the  beginning  and  end  of 
each  message  (Alber  and  Thomas,  1985:132).  The  control  bits  are  used  to 
define  the  message  type.  There  are  basically  two  types  of  messages,  the 
control  message  and  the  data  message.  The  control  messages  are 
necessary  for  the  operation  of  the  token-passing  media  access  method. 
Data  messages  carry  data  among  the  stations.  Examples  of  control  type 
messages  would  be  the  token  message,  where  a  station  is  passing  the 
token;  messages  that  allow  new  stations  to  join  and  exit  the  network; 
and  messages  that  initialize  the  network  (IEEE  802.4,  1982:4-3).  Other 


Information  can  also  be  Included  with  the  control  bits;  priority  bits  to 
Indicate  the  priority  of  the  message,  and  time  tag  bits  to  Indicate  when 
the  data  In  the  message  was  generated.  SA  Indicates  the  source  address 
bits  and  DA  Indicates  the  destination  address  bits  In  Figure  3.  These 
bits  are  used  to  Indicate  the  source  and  destination  of  the  particular 
message.  The  data  bits  labeled  Data  In  Figure  3  denote  the  data  being 
transferred  among  stations  or  data  associated  with  a  control  message. 

The  data  bits  can  be  an  optional  field  for  the  control  type  messages. 

For  example,  the  control  message  that  passes  the  token  would  not  have 
any  data  bits  In  It.  The  cyclic  redundancy  code  bits  labeled  CRC  In 
Figure  3  are  used  for  error  control.  This  allows  stations  to  detect 
errors  in  the  messages  they  receive. 

Token-Passing  Protocols 

There  are  currently  three  token-passing  protocols  that  have  been 
proposed  for  the  new  avionics  bus  network.  This  section  will  compare 
and  analyze  their  features.  A  fourth  protocol  defined  by  the  Institute 
of  Electrical  and  Electronics  Engineers  (IEEE)  In  their  effort  to 
standardize  local  area  networks  will  also  be  Included  In  the  analysis. 
The  other  three  protocols  have  been  proposed  by  the  Society  of 
Automotive  Engineers  (SAE)  as  part  of  their  aerospace  standards 
activities,  by  the  Collins  Government  Avionics  Division  of  Rockwell 
Corporation  as  part  of  a  contract  for  the  US  Air  Force's  Avionics 
Laboratory  Pave  Pillar  Program,  and  finally  by  the  US  Air  Force's 
Systems  Engineering  Avionics  Facility  (SEAFAC).  A  summary  of  the 
Important  features  of  each  protocol  Is  presented  In  Table  I.  A  dash  (-) 
in  a  column  for  an  Item  Indicates  that  this  Item  Is  undefined  or  not 


COMPARISON  OF  TOKEN-PASSING  PROTOCOLS 
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applicable  for  that  particular  protocol. 

The  response  time  Item  In  Table  I  refers  to  the  maximum  amount  of 
time  a  station  Is  allowed  to  take  In  responding  to  a  token  message 
addressed  to  It.  That  Is,  a  station  must  begin  transmitting  a  data  or 
token  message  within  the  response  time  maximum  limit.  If  no  response  Is 
heard  by  the  station  that  passed  the  token  (sending  station)  or  the 
central  controller,  depending  on  the  type  of  control  used  In  the 
network,  an  error  condition  Is  assumed  to  exist.  The  sending  station  or 
central  controller  then  takes  steps  to  overcome  this  error  condition. 
Station  servicing  refers  to  the  two  different  disciplines  available  to  a 
station  for  servicing  the  messages  It  has  waiting  to  be  transmitted. 

The  first  discipline  Is  called  exhaustive  servicing  where  all  messages 
pending  at  a  station  are  transmitted.  The  other  discipline  Is  called 
limited  servicing  which  only  allows  a  station  to  transmit  pending 
messages  until  a  time  limit  or  number  of  messages  limit  Is  reached 
(Cherukurl  et  al.  1982:60).  The  next  four  paragraphs  briefly  discuss 
the  Information  presented  In  Table  1  for  each  protocol. 

IEEE  Token-Passing  Protocol.  (IEEE  804.2,  1982)  The  draft  IEEE 
Token-Passing  Bus  Access  Method,  Standard  802.4,  Is  one  of  the  family  of 
standards  for  local  area  networks.  The  802.4  protocol  Includes  options 
for  a  1  megabit  per  second  (Mb/s)  baseband  network,  a  5  or  10  Mb/s 
baseband  network,  and  a  1  Mb/s  or  5  Mb/s  or  10  Mb/s  broadband  network. 
For  the  analysis,  the  10  Mb/s  baseband  network  was  used.  Referring  to 
Table  I,  a  maximum  bus  length  Is  not  directly  specified  In  the  standard 
because  different  types  of  cable  are  allowed  by  the  standard.  Instead, 
a  minimum  signal  strength  In  dB  Is  defined.  The  minimum  message  size 


Item  In  Table  I  contains  two  values  because  the  IEEE  draft  Standard 


allows  a  16  bit  or  a  48  bit  address  field.  However,  the  maximum  size  of 
the  message  Is  limited  to  65,568  bits  In  both  cases.  Only  the  16  bit 
address  field  Is  used  In  the  calculation  of  the  maximum  address  and 
maximum  group  address  Item  entries. 

SAE  Token-Passing  Protocol.  (SAE,  1985)  In  the  draft  of  the 
proposed  standard,  seven  bits  are  allowed  for  destination  and  source 
addresses,  but  a  total  of  eight  bits  are  allowed  In  the  address  fields. 
The  last  bit  Is  to  be  used  for  multi-cast  or  group  addresses,  but  the 
draft  standard  does  not  define  how  It  Is  to  be  Implemented. 

Avionics  Laboratory  Token-Passing  Protocol.  (Ludvlgson  and  Milton, 
1985)  The  contract  to  develop  this  protocol  Is  presently  In  progress  so 
many  details  of  the  protocol  have  not  yet  been  defined.  This  Is  the 
reason  why  so  many  Items  are  marked  with  a  dash  In  Table  I.  The 
Avionics  Laboratory  and  Rockwell  Collins  are  allowing  a  token  control 
option  In  the  protocol.  The  option  allows  a  second  token  control 
method,  that  of  a  centralized  type. 

SEAFAC  Token-Passing  Protocol.  (Alber  and  Thomas,  1985)  This 
protocol  uses  a  centralized  method  to  control  the  operation  of  the  bus. 
One  station,  designated  the  scheduler  station.  Is  responsible  for  bus 
Initiation,  error  detection  and  recovery,  and  setting  the  token  passing 
order.  This  protocol  has  a  characteristic  that  allows  the  token  to  be 
passed  along  with  the  data  In  one  message.  If  a  station  does  not  have 
data  to  send,  a  regular  token  message  Is  transmitted.  Including  the 
token  In  the  data  message  decreases  the  bus  overhead,  as  a  separate 
token  message  does  not  have  to  be  transmitted.  This  protocol  also 
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Figure  4.  Simple  Centralized  Token-Passing  Protocol  Simulation 


allows  more  than  one  data  message  to  be  sent  by  having  the  transmitting 
station  pass  the  token  back  to  itself  until  it  has  no  more  data  or  the 
token  holding  time  is  exceeded.  The  token  is  passed  to  the  next  station 
with  the  last  data  message  transmitted.  Figure  4  is  a  simplified  flow 
chart  representation  of  how  this  centralized  protocol's  steady-state 
operation  is  simulated  in  this  thesis.  The  Figure  starts  with  a  station 
having  just  received  the  token. 


Local  area  networks  can  be  described  by  their  topology  and  the 
method  used  to  control  how  the  stations  gain  access  to  the  network. 

Each  topology  and  access  method  has  Its  strong  and  weak  points  which 
must  be  analyzed  according  to  the  network's  application. 

Since  a  bus  topology  with  a  token-passing  access  method  Is  the 
preferred  method  for  a  new  avionics  local  area  network,  this  thesis  will 
develop  a  simulation  model  for  such  a  network.  The  simulation  model 
will  be  designed  with  enough  flexibility  to  model  all  the  previously 


described  protocols. 


III.  simulation  Model 


This  chapter  begins  with  a  brief  discussion  of  discrete  event 
simulation  concepts.  The  simulation  program  and  the  token-passing 
algorithm  are  described  and  defined  using  flow  charts.  The  various 
adjustable  bus  parameters  are  described  next.  Finally,  the  simulation 
program  design  Is  presented  using  structure  charts. 

Discrete  Event  Simulation 

Simulation  can  be  defined  as  experimentation  with  a  model  of  a 
system  (Shannon,  1983:20).  What  makes  simulation  so  popular  and 
powerful  Is  Its  ability  to  allow  a  nondlsruptlve  examination  of  an 
existing  system  to  learn  more  about  It  or  to  test  Improvements. 
Simulation  also  can  be  used  to  explore  the  performance  of  a  system  that 
does  not  yet  exist  (Mlttra,  1984:142)  or  which  can  not  be  readily 
analyzed . 

There  are  many  ways  simulation  models  can  be  classified.  Three 
examples  of  these  classifications  are  according  to  how  the  model 
represents  the  system,  the  model's  purpose,  and  how  the  model  represents 
change  within  the  system  (Schmidt,  1984:65).  When  a  simulation  model 
represents  change  within  the  system  as  occurring  only  at  Isolated  points 
In  time,  the  model  Is  classified  as  a  discrete  type.  When  the  model 
represents  change  as  continually  occurring  over  time,  the  model  Is 
classified  as  a  continuous  type  (Schmidt,  1984:65-66).  For  discrete 
models,  the  points  In  time  are  determined  by  the  occurrence  of  an  event. 
An  event  Is  when  something  happens  to  change  the  state  of  the  system 
(Shannon,  1975:109).  The  time  clock  In  discrete  simulations  Is  advanced 


in  varying  size  steps  of  time  to  when  the  next  event  occurs.  These 
steps  are  discrete  amounts  of  time,  hence  the  name  discrete  simulation. 

In  simulating  an  avionics  bus  network  In  this  thesis,  the  discrete 
event  type  of  simulation  Is  used  because  the  operation  of  the  bus  can  be 
characterized  by  various  events.  Examples  of  these  events  are  the 
arrival  of  a  message  at  a  station,  the  times  a  station  begins  and  ends 
transmission  of  a  message,  and  the  times  a  station  begins  and  ends 
transmission  of  a  token  message. 

Entitles.  Entitles  In  a  system  are  the  physical  or  symbolic 
components  of  the  system  (Schruben,  1983:101).  Entitles  are  Important 
In  a  simulation  model  because  their  Interactions  cause  events  to  be 
created  (Shannon,  1975:109).  For  the  avionics  bus  network,  the  entities 
of  the  system  would  be  the  bus  media,  the  stations,  and  the  messages. 
Entitles  are  described  by  their  attributes  (Schruben,  1983:102).  For 
example,  the  attributes  of  a  message  might  be  Its  size.  Its  point  of 
origin  (source  station),  and  Its  destination  station  (Fortier  and  Leary, 
1981:221). 

Simulation  Language.  (Schmidt,  1984:72-73)  The  simulation  model 
must  eventually  be  converted  to  a  form  understandable  by  the  computer. 
This  conversion  Is  carried  out  by  expressing  the  simulation  model  In  a 
general  purpose  computer  programming  language  or  a  special  purpose 
(simulation)  language.  There  are*  two  main  advantages  In  using  a  general 
purpose  language.  These  languages  provide  the  person  conducting  the 
simulation  a  maximum  amount  of  flexibility  In  the  design  of  the  model. 
Secondly,  at  least  one  of  these  languages  Is  probably  known  by  that 
person.  An  advantage  of  using  a  simulation  programming  language  Is  Its 


built-in  routines  to  accomplish  common  simulation  functions.  Two 
examples  of  these  routines  would  be  event  manipulation  subroutines  and 
time  keeping  mechanisms. 

Selected  Language.  The  Pascal  general  purpose  programming  language 
was  selected  for  use  In  this  thesis  for  a  number  of  reasons.  The  most 
Important  reason  was  that  the  flexibility  of  a  general  purpose  language 
was  needed  to  model  the  level  of  detail  desired  for  the  avionics  bus 
simulation  model.  Even  with  the  recent  growth  and  popularity  of 
simulation  languages,  Mlttra  reports  that  a  recent  survey  estimated  that 
75Z  of  all  discrete  event  simulations  were  performed  using  FORTRAN  or 
Pascal  languages  while  most  of  the  remaining  25%  were  performed  using 
the  GPSS  and  SIMSCRIPT  simulation  languages  (Mlttra,  1984:144). 

Simulation  Model  Program 

The  simulation  model  program  Is  divided  Into  three  main  sections 
that  are  described  below  and  shown  In  flow  chart  form  In  Figure  5.  The 
three  sections  are  setup,  simulation,  and  summary. 

Setup.  The  Setup  section  performs  all  the  data  Input  and 
Initialization  actions  that  are  necessary  before  the  actual  simulation 
can  take  place.  These  actions  accomplished  by  the  Setup  section  of  the 
simulation  program  are  shown  In  flow  chart  form  In  Figure  6.  The  Setup 
section  begins  by  reading  In  the  bus  configuration  data.  Next,  the 
arrival  time  and  length  of  the  first  message  for  each  station  Is 
calculated  and  the  message  Is  queued  at  Its  station.  Then,  the 
variables  that  will  store  the  data  for  all  the  statistics  concerning  the 
simulation  are  Initialized.  Finally,  the  token-passing  propagation 
delays  are  calculated  for  every  station  pair  and  this  Information  Is 
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Figure  5.  Simulation  Model  Program  Flow  Chart 


stored.  This  is  done  so  that  during  the  simulation  portion  of  the 
program,  the  token-passing  propagation  delays  can  simply  be  looked  up 
and  do  not  have  to  be  calculated  every  time  they  are  needed. 

Simulation.  This  section  of  the  simulation  program  performs  the 
actual  simulation  of  the  bus.  The  section  consists  of  two  main 
routines,  one  for  simulating  distributed  token-passing  protocols  similar 
to  the  one  defined  by  the  IEEE  802.4  specification,  and  the  other  for 
simulating  the  Systems  Engineering  Avionics  Facility  centralized  token- 
passing  protocol.  This  section  of  the  simulation  model  program  is 
described  in  detail  later  in  this  chapter  under  the  heading  Token- 
Passing  Algorithms. 
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Figure  6.  Setup  Section  Flow  Chart 


Summary.  The  actions  accomplished  by  the  Summary  section  of  the 
simulation  model  program  are  shown  In  flow  chart  form  In  Figure  7.  This 
section  performs  the  calculations  necessary  to  determine  the  values  for 
the  various  performance  parameters  for  the  bus  configuration  that  was 
simulated.  These  parameters  Include:  throughput,  message  statistics, 
access  delays,  message  delays,  number  of  token-passing  cycles,  and 
efficiency.  This  section  then  prints  these  parameter  values  in  a 
summary  format. 


•o. : 


Token-Passing  Algorithms 

The  token-passing  algorithms  are  the  main  part  of  the  simulation 
section  of  the  overall  program.  The  distributed  token-passing  algorithm 
is  shown  in  Figure  8  and  the  centralized  token-passing  algorithm  is 
shown  in  Figure  9.  In  the  figures,  the  abbreviation  "incr.  sim." 
represents  increase  simulation.  This  refers  to  Increasing  the  time  clock 
of  the  simulation  to  the  time  of  the  next  event.  The  abbreviation  "msg" 
represents  message  and  the  abbreviation  ”tx”  represents  transmission. 


Figure  8.  Distributed  Token-Passing  Algorithm 
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Figure  8.  Distributed  Token-Passing  Algorithm  (continued) 
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For  both  algorithms,  the  first  decision  that  is  made  is  whether  the 
station  has  any  messages  waiting  to  be  sent.  The  presence  of  messages 
waiting  to  be  sent  must  be  checked  because  a  station  may  have  a  very  low 
or  even  a  zero  rate  for  message  arrivals.  A  variety  of  arrival  rates 
are  allowed  so  different  traffic  loading  situations  may  be  simulated.  A 
message  arrival  rate  of  zero  would  correspond  to  a  station  with  no 
messages  to  send.  The  expression  ‘‘continuous  arrivals”  refers  to  the 
condition  where  a  station  always  has  messages  waiting  to  be  transmitted. 
Again,  the  reason  for  this  condition  is  so  different  traffic  loading 
situations  can  be  simulated. 

Token-Holding  Time  Limit.  The  token-holding  time  limit  can  be 
checked  by  a  station  either  before  a  message  is  transmitted  or  after  a 
message  has  been  transmitted.  In  a  token-passing  protocol  with  a 
maximum  message  size,  both  types  of  token-hold  time  limit  checks  would 
result  in  calculable  actual  station  token-holding  times  and  therefore 
deterministic  access  delays.  However,  a  before  transmission  check  keeps 
the  actual  maximum  station  token-holding  time  lower  than  an  after 
transmission  check.  The  only  way  to  achieve  this  same  lower  maximum 
token-holding  time  with  the  after  transmission  check  would  be  to 
artificially  restrict  the  token-holding  time  limit.  This  restriction 
does  not  allow  the  station  to  fully  utilize  its  token-holding  time  limit 
except  when  it  has  the  maximum  number  of  maximum  size  messages  ready  to 
transmit.  It  is  for  this  reason  that  both  algorithms  use  a  before 
transmission  check  of  the  token-holding  time  limit. 

In  the  case  of  the  centralized  token-passing  protocol,  this  before 
transmission  check  requires  a  station  to  not  only  check  the  next  message 


In  Its  message  queue,  but  also  to  check  the  second  message  if  there  Is 
one.  This  Is  because  the  token  must  be  passed  In  the  last  message 
transmitted  by  the  station.  Thus,  If  the  token-holding  time  will  run 
out  during  transmission  of  the  second  message,  the  station  only 
transmits  the  next  message  and  Includes  the  token  passing  Instruction  In 
It.  However,  since  no  actual  messages  are  being  send  In  the  simulation 
model  program,  the  centralized  algorithm  does  not  have  to  check  the 
second  message.  It  still  performs  a  before  transmission  check  of  the 
token-holding  time  limit  though.  If  the  limit  will  be  exceeded,  we 
assume  the  token  was  passed  In  the  last  message  transmitted. 

Assumptions.  Both  algorithms  assume  that  Initialization  of  the  bus 
has  taken  place;  that  Is,  a  complete  token-passing  order  has  been 
established  and  each  station  knows  to  whom  It  Is  to  pass  the  token.  The 
centralized  token-passing  algorithm  assumes  that  the  token-holding  time 
limit  allows  a  station  to  transmit  at  least  one  data  message  when  It  has 
one  or  more  ready  to  send,  because  that  Is  the  only  means  by  which  the 
token  can  be  passed  given  that  condition.  The  algorithms  have  been 
designed  to  model  their  respective  token-passing  protocol  under  the 
conditions  of  steady-state,  error  free  operation.  These  assumptions  are 
made  so  that  the  simulation  program  can  focus  on  modeling  the  protocols 
to  determine  their  performance  and  the  effect  the  various  bus  parameters 
have  upon  that  performance. 

Bus  Parameters 

The  various  bus  parameters  that  are  adjustable  In  the  simulation 
program  are  listed  below.  Also  Included  are  the  choices  available  when 
a  parameter  has  a  limited  number  of  values  It  may  take  on,  for  example 


the  type  of  message  arrival  condition  a  station  can  have. 

-  bus  environment 

bit  rate 

number  of  stations 
length  of  the  bus 
station  delay  time 
signal  propagation  speed 

-  protocol 

centralized  or  distributed  control 
token  holding  time  limit 
token  passing  order 
ascending 
descending 
fixed 


-  stations 

distance  from  left  end  of  the  bus 
type  of  message  arrival  condition 

deterministic  distribution 
Poisson  distribution 
continuous  case 
message  arrival  rate 
type  of  message  length  distribution 
deterministic 
exponential 

message  length  size  or  mean 

-  messages 

number  of  overhead  bits 

number  of  bits  In  token 

number  of  bits  In  a  data  word 

minimum  number  of  data  words  In  a  message 

maximum  number  of  data  words  In  a  message 


Message  Arrival  Types  and  Rates.  All  the  stations  on  the  bus  may 
have  the  same  type  of  message  arrival  condition.  All  the  stations  may 
have  the  same  arrival  rate  of  this  condition  or  they  may  all  have 
different  rates  of  this  condition.  However,  If  the  stations  all  have 
different  types  of  message  arrival  conditions,  all  their  rates  are 
assumed  to  be  different  and  are  read  In  on  a  Individual  basis  even 
though  they  might  be  the  same. 
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Message  Length  Distribution  Types  and  Means.  All  the  stations  on 
the  bus  may  have  the  same  type  of  message  length  distribution.  All  the 
stations  may  have  the  same  mean  for  this  distribution  type  or  they  may 
all  have  different  means.  However,  If  the  stations  all  have  different 
types  of  distributions,  all  their  means  are  assumed  to  be  different  and 

I 

are  read  In  on  a  Individual  basis  even  though  they  might  be  the  same.  i 

Simulation  Model  Program  Design 

The  structure  chart  method  was  used  as  an  aid  In  the  design  of  the 
simulation  model  program.  The  structure  charts  are  shown  In  Figure  10. 

A  goal  of  modularity  was  strived  for  in  the  design  of  the  software  so 
changes  or  added  functions  could  easily  be  Incorporated.  The  following 
paragraphs  describe  each  main  module  of  the  program. 

Module  0.0.  This  is  the  executive  module  for  the  program.  It  is 
decomposed  Into  three  modules  that  Implement  the  functions  of  the  three 
sections  described  earlier. 

Module  1.0.  This  module  Implements  the  functions  of  the  setup 
section.  It  accomplishes  this  by  calling  five  other  modules.  The  bus 
data  configuration  Input  Is  divided  Into  two  modules.  The  first  module, 
bus_data_lnput ,  reads  in  all  general  bus  configuration  data.  The  second 
module,  statlon_data_lnput,  reads  in  the  specific  data  about  each 
station.  An  example  of  the  modularity  of  the  program  is  shown  In  the 
Node  1.0  structure  chart  of  Figure  10.  The  calculate  arrival  and  length 
(calc_arr_and_len)  module  performs  the  basic  calculations  to  generate  a 
new  message  and  assign  It  an  arrival  time  and  length.  This  module  can 
be  called  by  any  other  module  for  any  station  when  a  new  message  Is 


needed. 
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Module  2.0.  This  module  Implements  the  functions  of  the  simulation 


section.  It  Is  decomposed  into  two  modules,  one  for  distributed,  and 
one  for  centralized  token-passing  protocols.  During  a  particular 
execution  of  the  simulation  model  program,  only  one  of  these  two 
protocols  can  be  simulated.  Each  protocol  module  can  call  on  six  other 
modules  to  update  data  statistics  variables,  generate  a  new  message 
arrival,  or  remove  a  message  that  has  been  transmitted,  as  It  performs 
the  simulation.  This  Is  shown  In  the  Node  2.X  structure  chart  of  Figure 
10.  Not  all  of  the  six  modules  might  be  called  for  a  particular 
station.  For  example.  If  the  station  had  continuous  type  message 
arrivals,  message  delays  would  not  apply  to  the  station.  Therefore,  the 
message  delay  statistics  would  not  be  calculated  or  updated  and  thus  the 
update  message  delay  statistics  module  (update_delay_stats)  would  not  be 
called . 

Module  3.0.  This  module  implements  the  functions  of  the  summary 
section  of  the  program.  Module  3.0,  statistics,  performs  the 
calculations  and  printing  of  access  delays  and  message  statistics  for 
each  station  as  well  as  a  summary.  It  calls  upon  the  two  other  modules 
to  calculate  and  print  message  delays  (Module  3.2),  and  token  cycles, 
throughput,  and  efficiency  (Module  3.1). 

Implementation 

The  simulation  model  program  was  designed  to  be  run  on  the 
sponsor’s  Digital  Equipment  Corporation  VAX  11/782  computer  running  the 
VAX/VMS  Version  4.2  operating  system.  The  simulation  model  was  coded  in 
the  Pascal  language.  Only  standardized  Pascal  language  constructs  were 
used  so  that  the  program  could  be  transported  to  other  computer  systems 


with  a  minimum  of  changes  and  or  problems.  However,  a  Digital  supplied 
uniformly  distributed  random  number  generator  run  time  library  function 
was  used  to  generate  random  numbers  for  the  message  arrival  and  length 
distribution  calculations. 

The  program  was  designed  to  be  executed  In  a  batch  mode.  This  was 
done  to  avoid  lengthy  delays  for  the  user  when  long  simulations  were 
being  run.  A  users  manual  for  the  simulation  model  program  Is  contained 
In  Appendix  A.  Also  Included  Is  an  example  of  the  program’s  output. 

The  simulation  model  program  software  Is  contained  In  Appendix  B. 

Execution.  A  user  submits  the  simulation  model  program  for 
execution  In  the  batch  mode  by  Invoking  a  command  file.  This  command 
file  contains  the  program  execution  Instruction  and  also  Includes  the 
data  needed  by  the  program  to  set  up  the  bus  configuration  to  be  tested. 
The  command  file  is  created  by  the  user,  separately  from  the  program, 
using  a  text  editor.  Thus,  the  user  has  the  option  of  selecting  an 
existing  bus  configuration  by  using  an  existing  command  file,  or 
defining  a  new  configuration  by  creating  and  using  a  new  command  file. 

Representation 

The  three  main  parts  of  a  bus  local  area  network  that  are 
represented  by  the  simulation  model  program  are  the  bus,  messages  and 
stations. 

Bus.  The  bus  Is  simply  represented  as  an  entity  that  transmits 


bits  at  a  certain  rate  with  no  errors.  The  propagation  delay  of  signals 
as  they  move  along  the  bus  Is  modeled.  The  speed  of  light  Is  multiplied 
by  an  adjustable  propagation  factor  to  determine  a  signal  propagation 


rate  and  associated  time  delay. 

Messages.  Messages  are  represented  as  entitles  that  move  through 
the  bus  local  area  network.  The  message  attributes  Include  Its  source 
station's  address,  size,  and  arrival  time.  The  messages  are  Implemented 
as  Pascal  records  with  the  message  attributes  as  fields  within  that 
record.  The  form  of  the  message  record  Is  shown  below. 

message_type  *  record 

80urce_add  :  integer  ; 
length  :  real  ; 
arr_tlme  :  real  ; 
end  ; 

Stations.  The  bus  stations  are  represented  as  entitles  that  are 

part  of  the  local  area  network.  The  station  attributes  Include: 

station  address 

passing  address 

message  arrival  type 

message  arrival  rate 

distance  from  start  of  bus 

message  length  distribution  type 

message  length  distribution  mean 

token  passing  propagation  time  to  next  station 

time  of  last  bus  access 

message  queue 


The  stations  are  Implemented  as  Pascal  records  with  the  station 
attributes  as  fields  within  that  record.  The  form  of  the  station  record 
Is  shown  below.  The  station's  message  queue  Is  represented  using  a 
single  linked  list. 


station_type  =  record 

address  :  Integer  ; 
pass_address  :  Integer  ; 
me8s_arr_type  :  arrival  ; 
mess_arr_rate  ;  real  ; 
distance  :  real  ; 
mess_len_type  :  length_distrib  ; 
mess_leo_mean  :  real  ; 
pass  prop_tlme  :  real  ; 


Iast_acces8  :  real  ; 
front_mess_queue  :  mes8age_ptr  ; 
rear_mes8_queue  :  me8sage_ptr  ; 
end  ; 


Performance  Parameters 

The  following  paragraphs  describe  how  the  various  performance 
parameters  are  calculated  by  the  simulation  model  program. 

Access  Delay.  Access  delay  Is  calculated  when  a  station  has  just 
received  the  token.  It  Is  the  difference  between  the  current  time  and 
the  time  when  It  last  received  the  token. 

Message  Delay.  Message  delays  are  calculated  If  a  station's 
message  arrival  distribution  Is  polsson  or  constant  with  a  non-zero 
arrival  rate.  The  delay  for  a  particular  message  Is  calculated  just 
after  It  has  been  transmitted.  The  delay  Includes  the  time  the  message 
has  been  waiting  to  be  transmitted  (queueing  time),  and  the  time  Its 
takes  to  be  transmitted  (Bux,  1981:158). 

Normalized  Delay.  The  normalized  delay  Is  the  mean  message  delay 
for  all  messages  divided  by  the  mean  message  length  transmission  time 
(Bux,  1981:169). 

Token-Passing  Cycle.  A  token  passing  cycle  Is  the  amount  of  time 
It  takes  for  the  token  to  be  passed  through  all  the  stations  on  the  bus. 

Throughput.  Throughput  Is  the  number  of  data  bits  transmitted 
during  one  token-passing  cycle  (Rahlml  and  Jelatls,  1983:800).  It  Is 
calculated  at  the  end  of  every  token-passing  cycle.  These  throughputs 
are  then  averaged  and  a  mean  throughput  Is  printed  as  part  of  the 


summary  statistics. 


Efficiency.  Efficiency  Is  the  number  of  data  bits  transmitted, 
divided  by  the  total  number  of  bits  (data  and  overhead)  transmitted 


during  one  token-passing  cycle  (Ludvlgson  and  Milton,  1983:127). 
Efficiency  Is  calculated  at  the  end  of  every  token  passing  cycle  and  a 
mean  efficiency  Is  printed  at  the  end  of  the  program  as  part  of  the 
summary  statistics. 

Summary 

Simulation  allows  experiments  to  be  conducted  on  real  and  non- 
exlstlng  systems  to  help  answer  performance  and  operation  questions.  A 
discrete  event  simulation  Is  being  used  In  this  thesis  to  explore  the 
performance  of  an  avionics  token-passing  bus.  An  overall  simulation 
model  program  Incorporating  token-passing  simulation  algorithms, 
simulation  control,  and  performance  calculations  was  designed  and 
Implemented  In  the  Pascal  language. 


IV.  Test  Results 


This  chapter  presents  the  results  of  testing  accomplished  to 
validate  the  simulation  model  program.  The  results  of  tests  using  a 
fighter-type  aircraft  bus  configuration  with  the  centralized  token¬ 
passing  protocol  are  also  presented  to  illustrate  how  the  different  bus 
design  factors  affect  this  protocol's  performance.  Finally,  a 
comparison  test  of  the  distributed  and  centralized  protocols  using  the 
fighter-type  bus  configuration  is  presented. 

Validation 

Validation  of  the  simulation  model  program  was  accomplished  through 
a  number  of  different  tests.  These  tests  were  designed  to  selectively 
test  a  certain  aspect  of  the  program. 

First  Validation  Test.  The  first  validation  test  was  designed  to 
test  the  continuous  type  of  message  arrival  condition  using  the 
distributed  token-passing  algorithm.  This  was  carried  out  using  a 
simple  bus  configuration  which  is  shown  in  Figure  11.  This  first 
validation  test  is  based  on  a  distributed  token-passing  protocol 
validation  and  evaluation  done  by  Rahiml  and  Jelatls  for  the  IEEE  802. A 
Protocol  (Rahimi  and  Jelatis,  1983:800-801).  There  are  six  stations 
spaced  evenly  on  a  500  meter  long  bus.  All  six  stations  have  messages 
to  send  and  they  always  have  messages  available.  The  message  size  is 
fixed  at  two  different  lengths,  864  data  bits  or  16224  data  bits.  There 
are  160  bits  of  overhead  in  a  message  and  the  token  is  also  160  bits  in 
length.  The  token  is  passed  in  ascending  station  address  order, 
starting  with  station  one.  A  bit  rate  of  10  Mb/s  and  a  station  delay 


Figure  11.  Simple  Bus  Configuration 


time  of  0.8  microseconds  are  used. 

The  condition  of  a  station  always  having  messages  available  to  send 
Is  modeled  by  a  continuous  message  arrival  condition.  The  token-holding 
time  was  adjusted  so  the  stations  could  only  send  1,  2,  4,  8,  or  16  of 
the  shorter  messages  and  1  or  2  of  the  longer  messages. 

In  order  to  validate  their  simulation  model,  Rahlml  and  Jelatls 
constructed  simple  test  cases  for  which  they  could  develop  relatively 
simple  formulas  for  the  token-passing  cycle  time  or  token  walk  time,  and 
throughput  (Rahlml  and  Jelatls,  1983:800).  The  formulas  were  then  used 
to  produce  analytic  values  for  throughput  which  were  compared  to  the 
values  produced  by  their  simulation  model.  They  first  defined  the 
token-passing  overhead  time  per  station: 

P  =  0  +  S  +  D  (1) 


where 

0  *  time  to  transmit  the  token  message  =  16  microseconds 
S  =  station  delay  time  »  0.8  microseconds 

D  *  mean  token-passing  propagation  delay  time  “  0.6667  microseconds 
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The  formula  for  the  token  walk  time  is  then 

W  -  (N)(P)  +  (M) (K) (F)  ^2) 

k 

where 

N  -  number  of  stations  on  the  network  *  6 
M  **  number  of  stations  with  data  to  transmit 
K  >  maximum  number  of  messages  a  station  can  transmit 
F  =  total  message  length  Including  data  and  overhead  In  bits 
R  •  bit  rate  *  10  megabits/second 
The  formula  for  throughput  is 

T  »  (M)  (K)  (L)  f.. 

W  ^  ' 


where 

L  =  number  of  data  bits  in  a  message 

The  results  of  this  validation  test  using  the  simulation  model 
program  along  with  Rahlml  and  Jelatis*  analytic  and  simulation  results 
are  shown  in  Table  II.  Each  row  of  Table  II  represents  one  run  of  the 
simulation  model  program.  Comparing  the  results.  It  Is  seen  that  this 
thesis  simulation  model  program's  results  are  In  closer  agreement  with 
Rahlml  and  Jelatis'  analytic  results  than  their  own  simulation  results. 
The  probable  reason  for  this  Is  their  more  detailed  simulation  model. 
Also,  they  give  no  description  of  how  throughput  was  calculated  In  their 
simulation  model.  Based  upon  the  close  slmularlty  between  the 
simulation  model  program's  results  and  Rahlml  and  Jelatis'  results,  this 
first  validation  test  was  successful. 


Table  II 


First  Validation  Test  Results 


Number  of 
messages 

sent 

Message 

size 

(bits) 

Throughput  (Mb/s) 

Rahlml/ Jelatls 

simulation 

Model 

Program 

analytic 

simulation 

1 

1024 

7.20 

7.10 

7.21 

2 

1024 

7.77 

7.70 

7.77 

4 

1024 

8.09 

7.89 

8.09 

8 

1024 

8.26 

8.18 

8.26 

16 

1024 

8.35 

8.26 

8.35 

1 

16384 

9.80 

9.63 

9.80 

2 

16384 

9.80 

_ 

9.80 

9.85 

Second  Validation  Test.  The  second  validation  test  was  designed  to 
test  a  case  In  which  the  message  load  Is  not  evenly  distributed  among 
the  stations.  This  test  utilized  both  the  deterministic  distribution 
and  continuous  case  message  arrival  conditions.  The  test  was  carried 
out  using  the  same  bus  configuration  as  the  first  validation  test. 
However,  In  this  test,  only  one  of  the  six  stations  has  messages  to  send 
and  It  always  has  messages  available.  This  second  validation  test  Is 
again  based  on  a  distributed  token-passing  protocol  validation  and 
evaluation  done  by  Rahlml  and  Jelatls  for  the  IEEE  802.4  Protocol 
(Rahlml  and  Jelatls,  1983:800-801).  Equations  (1),  (2),  and  (3) 
presented  In  the  first  validation  test  paragraph  also  apply  to  this 
validation  test. 
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Table  III 


Second  Validation  Test  Results 


Number  of 
messages 

sent 

Message 

size 

(bits) 

Throughput  (Mb/s) 

Rahimi/ Jelatis 

Simulation 

Model 

Program 

analytic 

simulation 

1 

1024 

4.17 

4.05 

4.17 

2 

1024 

5.58 

5.45 

5.58 

4 

1024 

6.71 

6.59 

6.72 

8 

1024 

7.48 

7.34 

7.48 

16 

1024 

7.93 

7.85 

7.93 

32 

1024 

8.18 

8.07 

8.18 

1 

16384 

9.30 

9.13 

9.31 

2 

16384 

9.60 

9.13 

9.60 

The  station  that  always  has  messages  available  to  send  Is  modeled 
by  a  continuous  message  arrival  condition.  The  other  stations  with  no 
messages  are  modeled  by  a  deterministic  distribution  message  arrival 
condition  with  an  arrival  rate  of  zero.  The  token-holding  time  is 
adjusted  so  that  a  station  may  send  1,  2,  4,  8,  16,  or  32  of  the  shorter 
messages  and  1  or  2  of  the  longer  messages.  The  results  for  the  test 
using  the  simulation  model  program  along  with  Rahimi  and  Jelatis' 
analytic  and  simulation  results  are  shown  in  Table  III.  Due  to  the 
close  agreement  between  the  simulation  model  program's  results  and 
Rahimi  and  Jelatis'  results,  this  second  validation  test  was  successful. 

Third  Validation  Test.  The  third  validation  test  is  similar  to  the 


first  except  it  is  conducted  using  the  centralized  token-passing 


Table  IV 


Third  Validation  Test  Results 


Number 

Message 

Throughput 

(Mb/s) 

Efficiency 

of 

messages 

sent 

size 

(bits) 

analy . 

sim. 

analy. 

sim. 

1 

1024 

8.32 

8.32 

.8438 

.8438 

4 

1024 

8.41 

8.41 

.8438 

.8438 

protocol.  The  test  was  designed  to  check  the  continuous  message  arrival 
condition  and  uses  the  bus  configuration  shown  in  Figure  11.  All  the 
other  bus  parameters  are  the  same.  However,  only  a  data  message  length 
of  864  bits  and  just  two  different  token-holding  time  limits  are  used. 
The  two  token-holding  time  limits  allow  the  stations  to  send  one  or  four 
messages.  The  results  of  this  validation  test  using  the  simulation 
model  are  shown  with  the  analytical  results  in  Table  IV.  This 
validation  test  was  successful  based  upon  the  consistent  results  between 
the  analytical  calculations  and  the  simulation  program's  values. 

Fourth  Validation  Test.  The  fourth  validation  test  is  similar  to 
the  second  except  it  is  conducted  using  the  centralized  token-passing 
protocol.  The  test  was  designed  to  check  the  deterministic  distribution 
message  arrival  condition  with  an  arrival  rate  of  zero  and  uses  the  bus 
configuration  shown  in  Figure  11.  All  the  other  bus  parameters  are  the 
same.  However,  only  one  data  message  length  of  864  bits  and  just  two 
different  token-holding  time  limits  are  used.  The  two  token-holding 
time  limits  allow  the  stations  to  send  one  or  four  messages.  The 
results  of  this  validation  test  using  the  simulation  model  are  shown 


Table  V 


Fourth  Validation  Test  Results 


Number 

Message 

Throughput 

(Mb/s) 

Efficiency 

of 

messages 

sent 

size 

(bits) 

analy. 

slm. 

analy. 

slm. 

1 

1024 

4.52 

4.52 

.4737 

.4737 

4 

1024 

6.93 

6.93 

.7059 

.7059 

along  with  the  analytical  results  in  Table  V.  Comparing  the  results 
indicates  total  agreement  between  the  analytical  calculations  and  the 
simulation  program's  results.  This  validation  test  was  successful. 

Fifth  Validation  Test.  The  fifth  validation  test  was  designed  to 
test  the  Poisson  distribution  message  arrival  condition  using  the 
distributed  token-passing  algorithm.  This  validation  test  is  based  on 
evaluations  of  token-passing  methods  conducted  by  Cherukuri,  Li,  and 
Louis  (Cherukuri  ^  1982:68).  The  bus  configuration  used  for  this 

test  is  shown  in  Figure  12.  There  are  50  stations  spaced  evenly  along  a 
2000  meter  bus.  The  message  arrival  rate  is  the  same  for  all  the 
stations.  The  message  size  is  fixed  at  a  constant  length  of  1000  data 
bits.  There  are  96  bits  of  overhead  in  a  message  and  the  token  message 
is  96  bits  long  also.  The  token  is  passed  in  ascending  station  order 
starting  with  station  number  one.  A  bit  rate  of  10  Mb/s  and  a  station 
delay  time  of  2  microseconds  are  used  for  the  test.  The  token-holding 
time  limit  was  fixed  at  120  microseconds,  which  allowed  the  stations  to 
transmit  one  message  per  access. 


Messages  arrive  at  the  stations  according  to  a  Poisson 
distribution.  All  stations  have  an  Identical  mean  arrival  rate.  This 
mean  arrival  rate  was  varied  between  30  and  300  messages/second  and  a 
number  of  runs  were  made  using  the  simulation  model  program.  The 
results  of  these  runs  are  compared  to  Cherukuri's  results  in  Figure  13. 
The  figure  shows  the  normalized  delay  (mean  message  delay  relative  to 
the  mean  message  transmission  time)  plotted  against  the  throughput  rate 
relative  to  the  bit  rate.  Based  upon  the  good  agreement  between  the 
simulation  program's  results  and  Cherukuri's  results,  this  validation 
test  was  successful. 

Sixth  Validation  Test.  The  sixth  validation  test  was  designed  to 
test  the  exponential  distribution  of  message  lengths.  This  validation 
test  is  based  on  a  distributed  token-passing  analysis  and  simulation 
study  conducted  by  Ulug  (Ulug,  1984).  Ulug  found  that  when  stations 
were  limited  to  transmitting  only  one  message  per  token-holding  turn, 
there  was  little  variation  in  the  mean  token-passing  cycle  time  when 
using  fixed  message  lengths  or  exponentially  distributed  message  lengths 
with  the  same  mean  (Ulug,  1984:39). 
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Table  VI 

Sixth  Validation  Test  Results 


total 

token- 

passing 

time 

(micro 

seconds) 

message 

length 

distri¬ 

bution 

type 

mean  token- 
passing 
cycle  time 
(milliseconds) 

standard 

deviation 

Ulug 

Simulation 

Model 

Program 

Ulug 

Simulation 

Model 

Program 

75.0 

fixed 

6,411 

6.412 

0.782 

0.000802 

125.0 

fixed 

10.575 

10.152 

0.854 

0.000901 

175.0 

fixed 

14.795 

13.694 

0.871 

0.000798 

75.0 

exp. 

6.252 

6.308 

1.219 

0.001052 

125.0 

exp. 

10.668 

10.062 

1.339 

0.001201 

175.0 

exp. 

14.707 

13.493 

1.467 

0.001151 

The  bus  configuration  used  for  this  validation  test  consisted  of 
fifty  stations  spaced  evenly  on  the  bus.  Ulug  does  not  indicate  the 
length  of  the  bus  but  rather  specifies  a  total  token-passing  time  which 
Includes  token  transmission  time,  token  propagation  time,  and  the 
station  delay  time.  Three  different  values  are  used  for  this  total 
token-passing  time;  75  microseconds,  125  microseconds,  and  175  micro¬ 
seconds.  A  message  is  864  bits  in  length.  The  message  overhead  is  160 
bits  and  the  token  is  also  160  bits  in  length.  A  5  megabit/second  bit 
rate  is  used. 


The  results  of  this  test  using  the  simulation  model  program  and 
Ulug's  results  are  shown  in  Table  VI.  The  difference  between  the 


simulation  model  program's  mean  token-passing  cycle  times  and  Ulug's 
times  exists  because  he  did  not  state  at  what  message  arrival  rate 
(load)  his  tests  were  run.  Also,  a  decimal  point  error  must  have  been 
made  In  his  calculation  of  the  standard  deviations.  However,  when 
comparing  the  values  In  Table  VI,  a  general  consistency  for  the  mean 
token-passing  cycle  times  and  standard  deviations  between  Ulug's  results 
and  the  simulation  model  program's  results  can  be  seen.  This  validation 
test  was  considered  successful. 

Validation  Tests  Summary.  All  the  validation  tests  were 
successful.  Since  no  other  simulation  or  analytical  results  exist  for 
the  cases  of  Poisson  type  arrivals  and  exponentially  distributed  message 
lengths  using  the  centralized  token-passing  protocol,  a  comparison  check 
between  the  distributed  and  centralized  software  was  done.  These 
checks,  along  with  the  knowledge  that  the  same  support  procedures 
(calc_arr_and_len  for  example)  are  called  by  both  protocol  algorithms, 
added  to  the  confidence  that  the  centralized  protocol  algorithm  was  also 
working  correctly.  These  validation  tests  and  checks  show  that  the 
simulation  program  successfully  models  a  bus  local  area  network  using  a 
distributed  or  centralized  token-passing  protocol. 

Aircraft  Test  Case 

Initial  performance  tests  of  the  centralized  token-passing  bus 
protocol  while  varying  some  of  the  bus  design  factors  were  conducted 
using  the  simulation  model  program.  The  bus  configuration  tested  was 
representative  of  an  avionics  local  area  network  for  a  fighter-type 
aircraft.  The  aircraft  size  Information  Is  based  on  the  dimensions  of 
the  F-15  aircraft  and  the  basic  bus  configuration  was  suggested  by  Alber 
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Figure  14.  Fighter-Type  Aircraft  Bus  Configuration 


(Alber,  1985).  The  bus  was  60  meters  in  length  and  had  30  stations 
connected  to  it.  The  stations  were  positioned  on  the  bus  corresponding 
to  where  avionics  would  normally  be  located.  These  locations  Included 
the  cockpit  area,  an  equipment  bay  aft  of  the  cockpit,  both  wing  areas 
and  the  tail  section.  The  stations  were  divided  evenly  among  these  five 
areas,  six  stations  to  an  area.  The  bus  configuration  is  shown  in 
Figure  14.  The  bus  starts  at  the  cockpit  (distance  0.0  meters),  goes  to 
the  left  wing,  then  to  the  right  wing  and  ends  at  the  tail  (distance 
60.0  meters).  The  bus  length  is  greater  than  the  physical  dimensions  of 
the  aircraft  because  the  actual  routing  distances  through  the  aircraft 
for  the  bus  cable  are  taken  into  account. 

Details  of  the  bus  configuration  are  as  follows.  There  are  70  bits 
of  overhead  in  a  message  and  the  token  message  is  22  bits  in  length.  A 
data  word  consists  of  16  bits.  There  can  be  a  minimum  of  zero  data 
words  and  a  maximum  of  256  data  words  in  a  message.  A  bit  rate  of  50 
megabits/second  is  used  and  the  station  delay  time  is  0.5  microseconds. 
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The  stations  are  allowed  to  hold  the  token  for  a  maximum  of  83.32 
microseconds,  which  Is  the  time  It  would  take  to  transmit  a  message  with 
the  maximum  number  of  data  words  In  It  (256).  The  token-passing  cycle 
starts  with  station  number  one  and  the  token  Is  passed  In  ascending 
order  based  upon  the  station's  address.  The  Poisson  distribution  type 
of  message  arrival  condition  Is  used  and  messages  have  exponentially 
distributed  lengths.  In  order  to  keep  the  message  size  within  the 
minimum  and  maximum  limits,  the  Initial  length  generated  Is  checked  by 
the  simulation  program  to  make  sure  It  Is  greater  than  or  equal  to  the 
minimum  length  and  less  than  or  equal  to  the  maximum  length.  If  the 
message  length  Is  outside  these  limits.  Its  value  Is  changed  to 
whichever  limit  It  exceeded. 

First  Test  Case.  The  first  test  case  for  this  fighter-type 
aircraft  bus  configuration  was  a  comparison  of  equal  and  unequal  station 
message  arrival  rates.  For  unequal  message  arrival  rates,  the  stations 
were  divided  Into  three  classes:  low,  medium,  and  high.  These  classes 
had  a  message  arrival  rate  ratio  of  1/5/50.  This  condition  of  unequal 
message  arrival  rates  was  used  to  simulate  the  different  data  output  or 
data  update  rates  that  avionics  have  or  require.  For  example,  mission 
or  fire  control  computers  produce  and/or  require  high  rates  of  data 
messages  per  second  In  order  to  accomplish  their  functions  with  the 
level  of  accuracy  needed  for  modern  military  aircraft.  The  stations’ 
addresses,  location  on  the  bus,  distance  from  the  left  end  of  the  bus, 
and  message  arrival  class  are  shown  In  Table  VII. 

For  the  equal  message  arrival  rate  simulation,  all  the  stations  had 
the  same  mean  message  arrival  rate.  This  mean  message  arrival  rate  was 


Table  VII 


Aircraft  Test  Case  Station  Data 


Station 


Location 


Distance 

(meters) 


Message  Arrival 


1 

Cockpit 

2.0 

Low 

2 

Cockpit 

2.5 

Medium 

3 

Cockpit 

3.0 

High 

4 

Cockpit 

3.5 

High 

5 

Cockpit 

4.0 

Medium 

6 

Cockpit 

4.5 

Low 

7 

Equip.  Bay 

5.0 

Low 

8 

Equip .  Bay 

6.0 

Medium 

9 

Equip.  Bay 

7.0 

High 

10 

Equip .  Bay 

8.0 

High 

11 

Equip .  Bay 

9.0 

Medium 

12 

Equip .  Bay 

10.0 

Low 

13 

Left  Wing 

13.0 

Low 

14 

Left  Wing 

14.0 

Medium 

15 

Left  Wing 

15.0 

High 

16 

Left  Wing 

16.0 

High 

17 

Left  Wing 

17.0 

Medium 

18 

Left  Wing 

18.0 

Low 

19 

Right  Wing 

28.0 

Low 

20 

Right  Wing 

29.0 

Medium 

21 

Right  Wing 

30.0 

High 

22 

Right  Wing 

31.0 

High 

23 

Right  Wing 

32.0 

Medium 

24 

Right  Wing 

33.0 

Low 

25 

Tall 

55.0 

Low 

26 

Tall 

56.0 

Medium 

27 

Tall 

57.0 

High 

28 

Tall 

58.0 

High 

29 

Tall 

59.0 

Medium 

30 

Tall 

60.0 

Low 

varied  from  300  messages  per  second  to  3500  messages  per  second.  For 
the  unequal  message  arrival  rate  simulation,  all  stations  In  a  class  had 
the  same  mean  message  arrival  rate.  However,  the  mean  rates  were 
different  among  the  three  classes.  The  mean  message  arrival  rates  were 
varied  from  10  to  2000  messages  per  second  for  the  Low  class,  50  to 
10,000  for  the  Medium  class,  and  500  to  100,000  for  the  High  class. 


Both  message  arrival  rate  simulations  used  exponentially  distributed 
messages  lengths  with  a  mean  of  64  data  words.  The  results  of  these 
simulations  are  shown  In  Figure  IS  as  normalized  delay-throughput 
curves . 

From  the  results.  It  can  be  seen  that  the  unequal  arrival  rate  case 
has  smaller  delays  for  medium  load  (throughput/blt  rate)  values.  At  low 
load  values,  both  the  equal  and  unequal  arrival  rate  conditions  delays 
are  very  similar;  while  at  very  high  load  values,  the  unequal  rate 
condition  has  higher  delays.  This  difference  In  delay  values  Indicates 
the  assumption  of  equal  mean  message  arrival  rates  for  stations  can  lead 
to  pessimistic  delay  values. 

The  command  files  used  to  provide  the  bus  configuration  data  to  the 
simulation  model  program  for  this  test  case  and  the  other  following  test 
cases  are  contained  In  Appendix  C. 

Second  Test  Case.  The  second  test  case  for  the  fighter-type 
aircraft  bus  configuration  was  a  comparison  of  different  mean  message 
lengths.  Simulations  were  done  with  mean  message  lengths  of  32  data 
words,  64  data  words  and  128  data  words.  All  three  simulations  used  the 
unequal  station  message  arrival  rate  condition  from  the  first  test  case 
with  the  same  mean  arrival  rates.  The  results  of  this  second  test  case 
are  shown  in  Figure  16  as  normalized  delay-throughput  curves. 

From  the  test  case  results.  It  can  be  seen  that  a  larger  mean 
message  size  results  In  higher  throughputs  for  the  same  amount  of  delay. 
This  Improvement  in  performance  can  be  explained  by  comparing  two 
networks  with  different  mean  message  lengths.  The  network  with  a  larger 
mean  message  size  will  be  transmitting  a  larger  number  of  data  bits  for 
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1-2-3-4-5-6-7-8-9-10-11-12-13-14- 


28-29-30-1 


optimum  token-passing  sequence 

1-30-2-29-3-28-4-27-5-26-6-25-7-  .  14-17-15-16-1 

worst-case  token-passing  sequence 

Figure  17.  Token-Passing  Sequences 

the  same  number  of  bus  accesses.  Rahlml  and  Jelatls  also  noted  higher 
throughput  and  efficiency  values  for  longer  message  lengths  (Rahlml  and 
Jelatls,  1983:801). 

Third  Test  Case.  The  third  test  case  for  this  fighter-type 
aircraft  bus  configuration  was  a  comparison  of  optimum  and  worst-case 
token-passing  sequences.  An  optimum  token-passing  sequence,  where  the 
token  is  passed  to  adjacent  stations,  was  compared  to  a  worst-case 
sequence.  In  the  worst-case  sequence,  the  token  Is  passed  to  the 
farthest  unvlsited  station  (Cherukuri  ^  al,  1982:59).  These  sequences 
are  shown  In  Figure  17.  For  these  simulations,  an  exponential  message 
length  distribution  with  a  mean  of  64  data  words  was  used.  The  unequal 
station  message  arrival  rate  condition  was  used  with  the  same  mean 
arrival  rates  as  In  the  previous  test  cases.  The  results  of  these 
simulations  are  shown  In  Figure  18  as  normalized  delay-throughput 
curves . 

From  the  test  case  results.  It  can  be  seen  that  there  Is  not  a 


significant  performance  difference  between  the  two  token-passing 
sequences.  It  Is  known  that  propagation  delays  due  to  station 
separation  and  bus  length  effect  the  performance  of  bus  networks  (Stuck 
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1983a:75-76).  However,  in  the  case  of  the  avionics  bus  configuration 
simulated  in  this  test  case,  the  token-passing  sequence  does  not  effect 
the  performance  of  the  bus  because  of  the  small  distances  involved  and 
the  high  bit  rate.  Since  most  avionics  buses  will  be  short  in  length, 
the  performance  degradation  due  to  propagation  delays  will  not  be  a 
significant  factor. 

Fourth  Test  Case.  The  fourth  test  case  using  the  fighter-type 
aircraft  bus  configuration  was  a  comparison  of  different  bit  rates. 
Simulations  were  performed  with  bit  rates  of  25  megabits/second,  40 
megabits/second  and  50  megabits/second.  All  three  simulations  used  the 
unequal  station  message  arrival  rate  condition  from  the  first  test  case 
with  the  same  mean  arrival  rates.  The  results  of  this  test  are  shown  in 
Figure  19  as  normalized  delay-throughput  curves. 

The  test  case  results  indicate  no  large  differences  in  the 
normalized  delay-throughput/bit  rate  ratio  curves  for  the  three 
different  bit  rates.  However,  when  the  non-normalized  mean  message 
delays  shown  in  Table  VIII  are  compared,  the  delays  at  25  Mbits/second 
are  approximately  twice  as  long  as  the  delays  at  50  Mbits/second  and  the 
delays  at  a  bit  rate  of  40  Mbits/second  are  approximately  a  third  longer 
than  at  50  Mbits/second. 

Fifth  Test  Case.  The  fifth  test  case  using  the  centralized  control 
protocol  in  a  fighter-type  aircraft  bus  configuration  involved  varying 
the  maximum  message  size.  Operation  of  the  centralized  control  protocol 
was  simulated  with  a  maximum  message  size  of  256  data  words,  1024  data 
words,  and  4096  data  words.  A  maximum  message  length  of  256  data  words 
was  chosen  for  one  of  the  test  cases  because  this  is  the  size  limit  used 


Table  VIII 


Fourth  Test  Case  Mean  Message  Delays 


mean  arrival 
rate 

(messages/second)  I  25  Mbits/sec 


186.6 


0.080 


Mean  Message  Delay 
(milliseconds) 


40  Mbits/sec 


0.049 


50  Mbits/sec 


0.040 


373.3 


0.103 


0.057 


0.045 


560.0 


0.132 


0.066 


0.051 


746.6 


0.167 


0.076 


0.056 


1120.0 


0.249 


0.104 


0.074 


1866.0 


0.393 


0.177 


0.117 


2240.0 


0.428 


0.200 


0.135 


3733.3 


0.565 


0.286 


0.203 


18666.0 


0.967 


0.540 


0.408 


37333.3 


1.114 


0.644 


0.497 


in  the  Systems  Engineering  Avionics  Facility  centralized  protocol.  A 
maximum  message  length  of  4096  data  words  was  chosen  for  this  test 
because  this  is  the  size  limit  used  in  both  the  SAE  and  Avionics 
Laboratory  distributed  protocols.  A  mean  message  length  of  64  data 
words  was  used  for  this  test  case.  This  test  used  the  unequal  station 
message  arrival  rate  condition  from  the  first  test  case  with  the  same 
mean  arrival  rates.  The  results  of  this  test  are  shown  in  Figure  20  as 
normalized  delay-throughput  curves. 

From  the  test  case  results,  it  can  be  seen  that  the  normalized 
delay-throughput  curves  are  very  similar  for  the  different  maximum 


message  lengths.  Also,  there  are  no  major  differences  in  the  mean 


message  delays.  Two  conditions  are  likely  to  have  contributed  to  this 
lack  of  variation  in  performance  parameters  for  this  test  case.  The 
first  is  that  the  same  value  for  the  mean  message  length  (64  data  words) 
was  used  for  all  three  maximum  message  length  simulations.  The  second 
condition  is  that  the  same  message  arrival  rates  were  also  used  for  all 
three  simulations.  The  simulations  with  the  smaller  maximum  message 
lengths  (256  and  1024  data  words)  actually  should  have  had  slightly 
higher  message  arrival  rates.  This  would  be  necessary  because  multiple 
messages  would  be  required  using  those  protocols  to  transfer  the  same 
amount  of  data  as  could  be  transferred  with  one  message  of  4096  data 
words  using  the  third  protocol. 

Sixth  Test  Case.  The  sixth  test  case  examined  the  effect  of  a 
different  type  of  message  arrival  distribution  on  the  centralized 
protocol  in  the  fighter-type  aircraft  bus  configuration.  A 
deterministic  distribution  message  arrival  condition  was  compared  to  a 
Poisson  distribution  condition.  The  unequal  station  message  arrival 
condition  from  the  first  test  case  with  the  same  mean  arrival  rates  was 
used  in  this  test.  The  deterministic  distribution  used  the  same  mean 
message  arrival  rates  used  for  the  Poisson  distribution.  The  results  of 
this  test  are  shown  in  Figure  21  as  normalized  delay-throughput  curves. 

Having  messages  arrive  according  to  a  Poisson  distribution  is  the 
normally  assumed  condition  in  queueing  systems  analyses,  as  this  type  of 
arrival  condition  successfully  models  the  random  arrival  of  messages  in 
real  systems  (Tanenbaum,  1981:58).  In  current  MIL-STD-1553  avionics  bus 
systems,  information  is  usually  updated  at  a  bus  station  at  a 
deterministic  rate.  This  is  done  because  the  bus  controller  follows  a 


defined  timing  cycle  in  requesting  and  providing  data  to  the  stations 
due  to  the  constraints  of  Its  hardware  and  software  components  (Boeing, 
1980:5-3).  However,  with  a  token-passing  protocol  for  a  new  avionics 
network,  this  practice  could  still  be  used  but  would  no  longer  be 
necessary.  From  the  test  case  results  shown  In  Figure  21,  It  can  be 
seen  that  no  significant  differences  exist  between  the  deterministic  and 
Poisson  arrival  distribution  delay-throughput  curves. 

Seventh  Test  Case.  The  seventh  test  case  compares  the  distributed 
control  and  the  centralized  control  protocols  using  the  fighter-type  bus 
configuration.  The  centralized  control  protocol  used  for  this  test  is 
the  same  one  used  for  all  the  previous  tests.  It  Is  based  on  the 
protocol  proposed  by  the  Systems  Engineering  Avionics  Facility.  The 
distributed  control  protocol  tested  is  based  upon  the  IEEE  802.4 
protocol.  Although  the  IEEE  protocol  has  a  maximum  bit  rate  of  10 
megabits/second,  a  bit  rate  of  50  megabits/second  Is  used  In  the 
distributed  control  protocol  for  this  test  in  order  to  obtain  a  more 
realistic  comparison.  A  50  megabits/second  bit  rate  might  be  obtained 
with  the  IEEE  protocol  If  fiber  optics  were  used  as  the  media.  The 
results  of  this  comparison  test  are  shown  in  Figure  22  as  normalized 
delay-throughput  curves. 

The  results  show  that  the  distributed  control  protocol's  normalized 
delay-throughput/blt  rate  ratio  curve  is  shifted  up  and  to  the  left  of 
the  centralized  protocol's  curve.  This  means  that  for  the  same 
throughput  value,  the  distributed  protocol  has  a  higher  message  delay 
time  than  the  centralized  protocol.  From  the  other  aspect,  for  the  same 
delay  value,  the  distributed  protocol  has  a  lower  throughput  rate  than 
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the  centralized  protocol.  This  poorer  performance  of  the  distributed 
protocol  results  from  Its  separate  token  message  and  larger  number  of 
overhead  bits  In  a  data  message  as  compared  to  the  centralized  protocol. 
However,  as  discussed  In  the  next  chapter,  the  distributed  protocol  may 
still  be  preferred  In  practice  for  other  reasons  In  spite  of  Its  poorer 
delay-throughput  performance. 

Summary 

The  simulation  model  program  developed  by  this  thesis  was  validated 
through  a  series  of  tests.  These  tests  allowed  the  operation  and 
performance  of  the  simulation  model  program  to  be  compared  to  published 
or  analytical  operation  and  performance  results.  Initial  tests  were 
conducted  using  the  centralized  token-passing  protocol  In  a  fighter-type 
aircraft  avionics  bus  configuration  to  determine  the  different  bus 
design  factors'  Influence  on  the  protocol's  performance.  A  comparison 
test  between  the  distributed  control  and  centralized  control  protocols 
was  also  conducted. 
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This  chapter  summarizes  the  testing  conducted  In  Chapter  IV  and 
Includes  a  discussion  of  how  the  testing  results  relate  to  an  avionics 
network  environment.  A  summary  of  this  thesis  Is  then  presented  along 
with  recommendations  for  future  studies. 

Summary  of  Test  Results 

The  validation  and  Initial  performance/parameter  variation  tests 
from  Chapter  IV  are  summarized  and  discussed  In  the  following 
paragraphs . 

Validation  Tests.  Validation  of  the  simulation  model  was  conducted 
In  stages  with  each  stage  adding  a  protocol  characteristic  to  the  model. 
As  each  characteristic  was  added,  the  complexity  of  the  model  increased. 
The  bus  and  protocol  parameters  for  many  of  the  tests,  especially  for 
the  distributed  control  protocol,  were  designed  to  duplicate  testing 
conducted  by  other  investigators  and  reported  in  the  literature.  Thus, 
the  simulation  model  program's  results  could  be  and  were  compared  to 
published  results.  In  the  case  of  the  centralized  control  protocol 
where  no  previous  work  existed,  the  test  results  were  compared  to 
analytical  results  for  the  simple  test  cases.  The  only  check  that  could 
be  accomplished  for  the  more  complicated  test  cases,  was  a  software 
cross-check  of  the  centralized  control  protocol  algorithm  with  the 
distributed  control  protocol  algorithm.  The  successful  outcome  of  all 
the  validation  tests  indicates  the  ability  of  the  simulation  program  to 
model  a  token-passing  protocol  bus  network. 


variation/performance  tests  were  conducted  to  determine  the  effect  of 
the  different  bus  and  protocol  parameters  on  the  performance  of  the 
centralized  control  protocol.  A  comparison  test  between  the  centralized 
and  distributed  protocols  was  also  conducted. 

Message  Arrival  Conditions.  The  various  avionic  equipment  on 
a  network  all  have  different  Information  transfer  requirements  based 
upon  their  function.  These  Information  transfer  requirements  can  be 
translated  Into  messages  sizes  and  transmission  rates  which  are  usually 
different  for  each  station.  This  results  In  a  condition  of  numerous 
unequal  station  message  arrival  rates.  This  message  arrival  condition 
could  be  modeled  by  the  simulation  model  program  since  It  allows  all 
stations  to  have  different  message  arrival  rates. 

Bit  Rate  Variation.  When  the  bit  rate  was  varied  in  the 
Fourth  Test  Case,  no  large  differences  were  noted  In  the  normalized 
delay-throughput  curves  for  the  three  rates.  However,  when  the  non- 
normallzed  mean  message  delays  were  compared,  there  were  differences. 

The  non-normallzed  mean  message  delays  at  25  megabits/second  were  more 
than  twice  as  long  as  the  delays  at  50  megabits/ second.  This  comparison 
raises  the  question  of  whether  throughput  or  message  delay  Is  the  most 
Important  performance  parameter  In  an  avionics  network.  In  most  cases, 
message  delay  Is  considered  the  most  Important  parameter  because  of  the 
real-time  nature  of  an  avionics  network.  A  station,  as  part  of  the 
aircraft's  avionics  system,  requires  Information  to  perform  Its 
function.  Since  the  aircraft  and  the  environment  around  It  are  changing 
at  a  rapid  rate.  Information  can  become  "old"  and  thus  worthless  very 


quickly  because  the  information  represents  an  condition  of  the  aircraft 
or  Its  environment  that  no  longer  exists.  Thus,  limits  on  mean  and 
worst  case  message  delays  are  required  to  make  sure  the  Information  Is 
received  by  a  station  before  the  Information  becomes  old  and  useless. 

For  some  avionics,  small  message  delays  are  not  as  critical  due  to 
the  function  the  avionics  are  performing  or  the  type  of  Information 
being  processed.  In  this  case,  message  delays  are  not  as  Important  and 
network  tradeoffs  can  be  made.  For  example,  a  lower  bit  rate  could  be 
used  reducing  the  complexity  and  the  cost  of  the  bus  and  station 
hardware  components. 

Although  the  25  megabits/second  bit  rate  Is  exactly  half  of  the  50 
megabit/second  bit  rate,  the  delays  for  the  25  megabit/ second  bit  rate 
were  more  than  twice  the  50  megabit /second  delays.  The  reason  for  this 
difference  Is  a  slightly  different  total  number  of  messages 
transmitted/total  number  of  station  accesses  ratio  and  a  slightly 
different  actual  mean  message  length  for  each  bit  rate  simulation. 

Protocol  Comparison.  In  the  Seventh  Test  Case,  the 
centralized  control  protocol  had  a  better  normalized  delay- throughput 
curve  than  the  distributed  control  protocol.  However,  from  an  overall 
avionics  network  system  viewpoint,  additional  factors  besides  delay- 
throughput  performance  must  be  considered.  While  the  distributed 
protocol  does  have  more  overhead  bits  In  a  message,  these  bits  allow 
more  bus  operation  options.  These  options  Include  more  addresses  which 
allow  additional  stations  on  the  bus,  and  more  subaddresses  for  groups 
of  stations.  Also  with  the  distributed  control  protocol,  control  of 
the  network  Is  shared  equally  by  all  stations.  This  avoids  problems  of 


single  points  of  failure  that  the  centralized  control  protocol  has  with 
Its  one  scheduler  station,  or  one  scheduler  station  and  one  backup 
scheduler  station.  Finally,  since  the  IEEE  802.4  protocol  Is  a  widely- 
accepted  standardized  protocol,  a  network  using  It  could  benefit  In  a 
number  of  possible  ways.  These  benefits  might  Include  having  multiple 
sources  of  proven  low-cost  station  hardware  components  available  for  use 
and  a  large  base  of  user  experience  to  draw  upon. 

The  IEEE  802.4  protocol  Is  not,  however,  completely  problem  free. 
The  biggest  difficulty  associated  with  the  protocol  Is  Its  complexity. 
This  complexity  Is  derived  from  all  the  bus  control  functions  that  must 
be  implemented  by  all  the  stations  that  make  up  a  network.  These 
functions  Include  Initiating  a  token-passing  sequence,  recovering  from 
fault  conditions  caused  by  lost  or  multiple  tokens,  and  allowing 
stations  to  enter  or  exit  the  token-passing  sequence  (Myers,  1982:36). 

Thesis  Summary 

This  thesis  developed  and  validated  a  model  for  simulating  bus 
token-passing  protocols  for  avionics  applications.  The  purpose  of  the 
simulation  model  was  to  explore  the  effect  of  the  different  bus  and 
protocol  parameters  on  the  performance  of  the  bus.  Two  separate 
protocols  were  modeled,  that  of  a  protocol  with  distributed  control  and 
a  protocol  with  centralized  control.  The  model  was  developed  as  part  of 
an  overall  simulation  program  which  Included  simulation  control,  data 
collection,  and  data  analysis  functions.  The  simulation  model  program 
was  written  In  the  Pascal  computer  programming  language.  A  series  of 
tests  were  conducted  using  the  simulation  model  program  to  validate  Its 
operation  and  modeling  capabilities.  The  validation  tests  were 
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successful.  Initial  performance  tests  under  varying  bus  and  protocol 
design  parameter  conditions  were  conducted  for  the  centralized  token- 
passing  protocol  using  the  simulation  model  program.  Finally,  the 
performance  of  the  centralized  control  and  distributed  control  protocols 
were  compared. 

The  simulation  model  program  developed  by  this  thesis  provides  an 
analysis  capability  for  the  centralized  control  protocol  where  none 

existed  before.  Due  to  the  large  number  of  bus  and  protocol  parameters 
that  can  be  varied,  the  simulation  model  program  provides  a  capability 
for  detailed  analysis  of  the  performance  of  a  protocol  in  a  variety  of 
network  configurations  and  environments.  Also,  since  the  simulation 
model  program  Is  modular  In  design  and  construction,  additional  protocol 
characteristics  can  be  added  If  a  more  detailed  modeling  capability  Is 
needed  or  as  more  characteristics  become  known  as  the  definitions  for 
the  next-generation  avionics  network  protocol  are  refined. 

Recommendations 

Four  recommendations  concerning  the  simulation  model  program  are 
presented  and  discussed  In  the  following  paragraphs. 

First  Recommendation.  The  testing  done  in  Chapter  IV  using  the 
centralized  token-passing  protocol  algorithm  was  not  meant  to  be  a 
comprehensive  test  of  the  performance  of  this  protocol.  It  was  meant  to 
demonstrate  the  capabilities  of  the  simulation  model  program  and  explore 
basic  performance  questions  concerning  the  centralized  token-passing 
protocol.  Thus,  the  first  recommendation  would  be  to  continue  the 
performance  testing  of  the  centralized  token-passing  protocol.  An 
example  of  additional  tests  that  could  be  accomplished  would  be  testing 


the  protocol  with  a  standard  network  message  scenario  being  developed 
under  the  Avionics  Laboratory  contract  (Klass,  1985;169).  The  scenario 
Is  meant  to  realistically  define  the  number  of  stations  and  their 
message  loads  for  an  advanced  fighter  avionics  network. 

Second  Recommendation.  The  second  recommendation  is  to  use  the 
simulation  model  program  to  explore  the  performance  of  other  token¬ 
passing  protocols.  This  would  Include  the  protocols  being  considered 
for  use  In  the  next-generation  avionics  local  area  network  and  the  IEEE 
802.4  protocol  in  an  avionics  configuration.  The  IEEE  protocol  Is 
Included  In  this  recommendation  because  of  the  large-scale  Interest, 
previous  studies,  and  current  work  Involving  this  standardized  protocol. 

Third  Recommendat Ion.  The  third  recommendation  involves  an 
Improvement  to  the  simulation  model  program.  This  recommendation  would 
Involve  changing  the  bus  and  station  data  Input  method  to  a  more 
Interactive  type  of  user  interface.  This  would  involve  changing  the 
building  of  the  command  file,  which  executes  the  program,  from  an  off¬ 
line  to  an  Interactive  "question  and  answer"  type  interface.  This  would 
relieve  the  user  from  many  of  the  details  concerning  the  formatting  of 
the  bus  configuration  and  station  data. 

Fourth  Recommendation.  The  fourth  recommendation  concerns  an 
addition  to  the  protocol  algorithms.  It  Is  recommended  that  the 
capability  for  message  and/or  station  priorities  be  added  to  the 
protocol  algorithms.  The  capability  for  message  and  station  priorities 
is  Important  because  It  allows  time-critical  messages  to  be  transmitted 
with  low  delays  without  undue  performance  degradation  for  other  messages 
or  stations.  The  priority  option  is  especially  important  in  real-time 


environments  such  as  avionics  networks.  For  example,  a  message  priority 
capability  could  be  obtained  in  the  simulation  model  program  by  adding 
additional  message  queues  (linked  lists)  in  the  record  representation  of 
a  station.  Each  additional  message  queue  would  represent  lower  priority 
messages.  Also,  an  additional  field  would  have  to  be  added  to  the 
record  representation  of  a  message  to  indicate  the  message's  priority. 

Summary 

The  validation  and  Initial  performance  tests  conducted  using  the 
simulation  model  program  were  summarized  and  discussed  in  relation  to 
the  avionics  network  environment.  The  thesis  was  summarized  and 
recommendations  made  for  the  Improvement  of  the  simulation  program  and 
additional  study  efforts.  The  validated  simulatio  i  model  program 
developed  by  this  thesis  can  be  a  tool  for  further  token-passing 
protocol  performance  testing  and  evaluation. 


Appendix  A.  User's  Guide 

This  appendix  Is  the  simulation  model  program  user's  guide.  How 
the  program  Is  executed  Is  discussed  first.  This  Is  followed  by  an 
explanation  of  the  format  for  the  Input  data  and  definitions  of  the 
Input  data  variables. 

Program  Execution 

The  simulation  model  program  Is  executed  In  a  batch  mode.  It  Is 
submitted  for  execution  by  using  the  “submit**  command.  The  format  of 
the  submit  command  Is: 

submlt/log~[ ]  file  name 

There  are  various  other  options  of  the  submit  command  and  the  user 
should  consult  the  various  Digital  Equipment  Corporation  reference 
manuals,  such  as  the  VAX/VMS  Command  Language  User's  Guide  and  the 
Programming  In  VAX-11  Pascal  Manual  for  more  detailed  Information.  The 
**log>‘[}”  qualifier  names  the  program's  output  file  the  same  name  as 
"file  name"  but  with  a  ".log"  extension  and  places  It  In  the  current 
default  directory.  The  file  named  by  "file  name"  Is  a  command  file  that 
contains  the  program  execution  statement  and  the  Input  data  needed  by 
the  simulation  model  program.  The  file  named  by  "file  name"  should  have 
a  ".com"  extension.  This  command  file  Is  created  using  a  text  editor 
such  as  Digital  Equipment  Corporation's  EDT. 

Command  File 

The  command  file  has  three  parts  consisting  of  the  program 
execution  statement,  the  bus  data  Input  lines,  and  the  station  data 
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Input  lines.  These  three  parts  will  be  described  In  the  following 
paragraphs . 

Program  Execution  Statement.  The  first  line  In  the  command  file  Is 
always  the  program  execution  statement.  This  statement  Is  shown  below. 

$  run  dlsk$user: [spleth.busjbusslm 
This  statement  Instructs  the  VAX/VMS  operating  system  to  run  the  file 
"busslm"  In  the  directory  "spleth.bus**  on  the  "user**  disk.  The  file 
"busslm"  contains  the  main  Pascal  module  of  the  simulation  model 
program.  The  Initial  dollar  sign  must  be  Included  In  the  statement. 

Bus  Data  Input  Lines.  The  data  for  the  bus  configuration  that  Is 
to  be  simulated  Is  passed  to  the  simulation  model  program  by  Including 
the  data  In  the  command  file.  The  data  follows  the  program  execution 
statement  In  the  command  file.  The  format  of  the  bus  data  Input  lines 
are  shown  below.  The  description  Includes  the  name  of  the  variable,  the 
actual  name  used  In  the  program,  what  type  the  variable  Is,  and  an 
explanation  of  the  meaning  of  the  variable.  The  line  numbers  listed  are 
for  reference  only  and  are  not  part  of  the  command  file.  The  lower  case 
letters  after  the  line  number  refer  to  the  order  of  the  variables  on  the 
line.  On  line  3,  for  example,  the  variable  description  labeled  3a  would 
be  first  on  the  line  followed  by  3b  and  3c,  etc.  Blank  spaces  between 
the  variables  on  the  same  line  are  Ignored  by  the  program. 

For  real  type  variables,  a  digit  must  be  listed  both  before  and 
after  the  decimal  point  (0.5  Instead  of  .5).  When  the  explanation  for  a 
variable  states  that  It  Is  not  currently  Implemented  In  the  program,  or 
It  Is  not  used  based  upon  a  certain  condition,  a  value  still  has  to  be 
Included  In  the  data  for  this  variable  In  order  to  avoid  execution  errors. 


Line  Number 


Variable  Name 


2a.  random  number  generator  seed  seed  Integer 

This  Is  the  seed  for  the  Digital  Equipment  Corporation  random 
number  generator  which  Is  used  In  generating  arrival  times  for  Poisson 
arrivals  and  message  lengths  for  exponential  distributions. 

3a.  number  of  stations  num_stations  integer 

This  Is  the  total  number  of  stations  on  the  bus. 

3b.  first  station  flrst_statlon  Integer 

This  Is  the  address  of  the  station  that  the  simulation  program 
should  begin  the  token-passing  cycles  with.  It  Is  currently  not 
Implemented  In  the  program.  The  program  begins  the  token-passing  cycle 
with  the  station  whose  data  Is  listed  first  In  the  station  data  part  of 
the  Input  data. 

3c.  bit  rate  bit_rate  real 

The  rate  at  which  the  bits  are  transmitted  In  bits/second. 

4a.  propagation  factor  prop_f actor  real 

A  value  less  than  one  that  Is  multiplied  times  the  speed  of  light 
to  give  a  bus  signal  propagation  speed.  Typically  this  factor  Is 
0.6667. 

4b.  length  of  the  bus  bus_length  real 

The  length  of  the  bus  In  meters. 

4c.  station  delay  time  stat_delay  real 

The  amount  of  time  (In  seconds)  It  takes  a  station  to  start 
transmitting  either  a  data  or  token  message  once  It  has  received  the 
token. 

5a.  type  of  bus  control  bus__control  enumerated 

The  type  of  control,  either  distributed  (dlstrlb)  or  centralized 
(central),  used  In  the  token-passing  protocol.  Enumerated  type 
variables  can  not  be  read  In  or  printed  out.  Therefore,  for  Input,  a  0 
Is  meant  to  be  distributed  type  control  and  a  1  to  be  centralized  type 
control. 


Line  Number 


Variable  Name 


Sb.  direction  of  token  passing 


token_pass 


enumerated 


Defines  in  what  order  or  direction  the  token  is  passed  based  upon 
the  stations'  addresses.  There  are  three  types;  ascending  (ascen), 
descending  (descen),  and  fixed  (fixed).  For  input;  0  equals  ascen,  1 
equals  descen,  and  2  equals  fixed.  This  variable  is  not  Implemented  in 
the  program  at  this  time. 


5c.  type  of  token-holding  limit 


token_hold_type 


enumerated 


Defines  if  the  token-holding  limit  is  a  time  value  (time)  or  a 
limit  in  terms  of  number  of  messages  (num)  that  can  be  transmitted. 


5d.  token  holding  limit 


token  hold  limit 


The  length  of  time  a  station  may  transmit  messages  (in  seconds)  or 
the  number  of  messages  a  station  can  transmit  during  one  token-holding 
turn. 


6a.  same/different  arrival  type 


station  arr 


enumerated 


Defines  if  all  the  stations  have  the  same  type  of  arrival 
condition.  There  are  two  choices,  same  (same)  or  different  (diff). 
For  input;  0  equals  same,  and  1  equals  different. 


6b.  arrival  type 


statlon_arr_type 


enumerated 


If  the  stations  all  have  the  same  type  of  arrival  condition,  this 
variable  defines  which  type  it  is.  There  are  three  choices,  arrivals 
according  to:  a  deterministic  distribution  (constantjarr),  a  Poisson 
distribution  (Poisson),  or  a  continuous  case  (contln).  For  input;  0 
equals  deterministic,  1  equals  Poisson,  and  2  equals  continuous.  This 
variable  is  not  used  when  the  stations  have  different  types  of  arrival 
conditions;  that  is,  when  the  statlon_arr  variable  equals  diff. 


same/different  arrival  rate 


station  rate 


enumerated 


Defines  if  all  the  stations  have  the  same  arrival  rate.  There  are 
two  choices:  same  (same)  or  different  (diff).  For  input,  0  equals  same, 
and  1  equals  different.  This  variable  is  not  used  when  the  stations 
have  different  types  of  arrival  conditions;  that  is,  when  the 
statlon_arr  variable  equals  diff. 


arrival  rate 


station  arr  rate 


This  variable  represents  the  arrival  rate  of  messages  to  a  station 
(messages/second).  This  variable  is  only  used  if  the  stations  all  have 
the  same  type  of  arrival  condition  with  the  same  rate;  that  is,  both  the 
station  arr  and  station  rate  variables  must  be  equal  to  same. 


7a.  same/different  length  distribution  statlon_len  enumerated 

Defines  if  all  the  stations  have  the  same  type  of  message  length 
distribution.  There  are  two  choices,  same  (same)  or  different  (dlff). 
For  Input;  0  equals  same  and  1  equals  different. 

7b.  length  distribution  type  statlon_len_type  enumerated 

If  the  stations  all  have  the  same  type  of  message  length 
distribution,  this  variable  defines  which  type  It  Is.  There  are  two 
choices,  deterministic  (constant_len)  or  exponential  (exp).  For  Input; 

0  equals  deterministic  and  1  equals  exponential.  This  variable  is  not 
used  when  the  stations  have  different  types  of  message  length 
distributions;  that  is,  when  the  statlon_len  variable  equals  different 
(dlff). 

7c.  same /different  length  mean  statlon_mean  enumerated 

Defines  If  all  the  stations  have  the  same  mean  message  length. 

There  are  two  choices:  same  (same)  or  different  (dlff).  For  input,  0 
equals  same  and  1  equals  different.  This  variable  Is  not  used  when  the 
stations  have  different  types  of  message  length  distributions;  that  Is, 
when  the  statlon_len  variable  equals  different  (dlff). 

7d.  length  mean  statlon_len_mean  real 

The  mean  message  length  In  data  words.  This  variable  Is  only  used 
If  the  stations  all  have  the  same  type  of  message  length  distribution 
with  the  same  mean  message  length;  that  Is,  both  the  statlon_len  and 
statlon_mean  variables  must  be  equal  to  same.  Note:  when  the  message 
length  distribution  Is  of  the  deterministic  type,  the  mean  represents 
the  size  of  the  message. 

8a.  number  of  bits  In  token  token_blts  real 

The  number  of  bits  In  the  token  message. 

8b.  number  of  overhead  bits  In  a  message  overhead_blts  real 

The  number  of  header  and  trailer  bits  (overhead)  In  a  message. 
Includes  everything  but  the  data  bits. 

8c.  number  of  bits  In  one  data  word  blts_j>er_data_word  real 

The  number  of  bits  In  one  data  word. 

9a.  minimum  number  of  data  words  mln_data_words  real 

Defines  the  minimum  number  of  data  words  allowed  to  be  sent  In  a 
message.  Usually  would  be  zero  or  one. 


9b.  maximum  number  of  data  words  max_data_words  real 

Defines  the  maximum  number  of  data  words  allowed  to  be  sent  In  a 
message. 

10.  simulation  stop  time  slm_stop__tlme  real 

The  value  of  the  simulation  clock  when  the  simulation  should  be 
stopped.  The  simulation  clock  starts  at  value  0.0. 

11.  calculate  token  passing  propagation  delay  times  flag 

calc_j)ass_prop_tlme  boolean 

Determines  If  the  token-passing  propagation  time  delays  should  be 
calculated  or  read  In. 

Station  Data  Input  Lines.  Depending  on  a  station's  type  of  arrival 
condition  and  type  of  message  length  distribution,  from  one  to  three 
lines  of  data  may  need  to  be  read  In  to  completely  describe  a  station. 
Lines  XX,  YY,  and  ZZ  define  the  data  that  Is  on  these  lines.  At  the 
minimum,  there  would  be  one  line  of  data  for  each  station.  At  the 
maximum,  three  lines  of  data  could  be  used  for  each  station.  The  first 
station  listed  Is  the  station  the  simulation  model  program  will  begin 
the  token-passing  cycle  with.  The  rest  of  the  stations  are  then  listed 
In  the  order  they  are  passed  the  token. 


Line  Number  Variable  Name 


XXa.  station  address  (pointer) '.attrlb.address  Integer 

The  station's  address. 

XXb.  passing  address  (pointer) *.attrlb.pass_address  Integer 

The  address  of  the  .'tatlon  that  the  current  station  passes  the 
token  to. 

XXc.  distance  (pointer) '.attrlb.dlstance  real 

The  distance  from  the  left  starting  point  of  the  bus  to  the  current 
station  In  meters.  Only  used  If  the  calculate  token-passing  propagation 
delay  times  flag  Is  true  (1).  A  value  needs  to  be  listed  In  either 
case. 


Line  Number 


Variable  Name 


Type 


XXd.  token-passing  propagation  delay  time 

(pointer)  '".attrlb.pass_prop_tlme  real 

The  time  (In  seconds)  It  takes  the  token  to  propagate  from  the 
current  station  to  the  next  station.  Only  used  If  the  calculate  token¬ 
passing  propagation  delay  times  flag  Is  false  (0).  Values  only  need  to 
be  listed  when  the  flag  Is  false. 

YYa.  station  arrival  rate  (pointer)"  .attrlb.mess_arr_rate  real 

The  particular  station's  message  arrival  rate.  This  line  of  data 
Is  needed  only  If  the  stations  all  have  the  same  type  of  message  arrival 
condition  but  different  arrival  rates.  That  Is,  the  statlon_arr 
variable  would  be  equal  to  same  (same)  and  the  statlon_rate  variable 
would  be  equal  to  different  (dlff). 

OR 

YYa.  station  arrival  type  (pointer)  ".attrlb.mess_arr_type  enumerated 

YYb.  station  arrival  rate  (pointer)  ".attrlb.mess_arr_rate  real 

The  particular  station's  type  of  message  arrival  condition  and 
the  arrival  rate.  This  line  of  data  Is  needed  only  If  the  stations  all 
have  different  types  of  message  arrival  conditions.  That  Is,  the 
statlon_arr  variable  would  be  equal  to  different  (dlff). 

ZZa.  station  message  length  mean 

(pointer)" .attrlb.mess_len_mean  real 

The  particular  station's  mean  message  length.  This  line  of  data  Is 
needed  only  If  the  stations  all  have  the  same  type  of  message  length 
distribution  but  different  means.  That  Is,  the  statlon_len  variable  Is 
equal  to  same  (same)  and  the  statlon_mean  variable  Is  equal  to  different 
(dlff). 

OR 

ZZa.  station  message  length  distribution 

(pointer)". attrlb.mess_len_type  enumerated 

ZZb.  station  message  length  mean 

(pointer)" .attrlb.mess_len_mean  real 

The  particular  station's  type  of  message  length  distribution  and 
Its  mean.  This  line  of  data  Is  needed  only  If  the  stations  all  have 
different  types  of  message  length  distributions.  That  Is,  the 
statlon_len  variable  Is  equal  to  different  (dlff). 
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Sample  Output. 


!  Second  Test  Case  Mean  Message  Length  -  32  Data  Words 
$  run  dlsk$user : [spleth.bus]busslm 
select  bus  configuration  module 
868 

30  1  50.0e6 

0.666666666  60.0  O.Se-6 

1  20  83.32e-6 

0  11  400.0 

0  10  32.0 

22.0  70.0  16.0 

0.0  256.0 

0.6 

station  data  Input  module 
1 

1  2  2.0 

40.0 

2  3  2.5 

200.0 

3  4  3.0 

2000.0 

4  5  3.5 

2000.0 

5  6  4.0 

200.0 

6  7  4.5 

40.0 

7  8  5.0 

40.0 

8  9  6.0 

200.0 

9  10  7.0 

2000.0 

10  11  8.0 

2000.0 

11  12  9.0 

200.0 

12  13  10.0 

40.0 

13  14  13.0 

40.0 

14  15  14.0 

200.0 

15  16  15.0 

2000.0 

16 

2000.0 


17 


16.0 


23 


31.0 


2000.0 
22 
2000.0 

23  24 
200.0 

24  25 
40.0 

25  26 
40.0 

26  27 
200.0 

27  28 
2000,0 

28  29 
2000.0 

29  30 
200.0 

30  1 
40.0 

calc  first 
Inlt  stats 
1 
2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 


m 


arr  and  len  module 
module 

2.50000E-09 
2.50000E-09 
2.50000E-09 
2.50000E-09 
2.50000E-09 
2 , 50000E-09 
5.00000E-09 
5.00000E-09 
5.00000E-09 
5.00000E-09 
5.00000E-09 
1.50000E-08 
5.00000E-09 
5.00000E-09 
5.00000E-09 
5.00000E-09 
5.00000E-09 
5.00000E-08 
5.00000E-09 
5,OOOOOE-09 
5.00000E-09 
5.00000E-09 
5.00000E-09 
1 . lOOOOE-07 
5.00000E-09 
5.00000E-09 


Station 

Address 


Number 

of 

access 


Average 

access 

delay 

(seconds) 


Mlnlmiun 

access 

delay 

(seconds) 


Maximum 

access 

delay 

(seconds) 


1 

16009.0 

3.74811E-05 

2.72989E-05 

1.93834E-04 

2 

16009.0 

3.74811E-05 

2.72989E-05 

1.93834E-04 

3 

16009.0 

3.74811E-05 

2.72989E-05 

1.93834E-04 

4 

16008.0 

3.74817E-05 

2.72989E-05 

1.93834E-04 

5 

16008.0 

3.74818E-05 

2.72989E-05 

1.98632E-04 

6 

16008.0 

3.74818E-05 

2.72989E-05 

1.98632E-04 

7 

16008.0 

3.74818E-05 

2.72989E-05 

1.98632E-04 

8 

16008.0 

3.74818E-05 

2.72989E-05 

1.98632E-04 

9 

16008.0 

3.74818E-05 

2.72989E-05 

1.98632E-04 

10 

16008.0 

3.74817E-05 

2.72989E-05 

1.79127E-04 

11 

16008.0 

3.74817E-05 

2.72989E-05 

1.77890E-04 

12 

16008.0 

3.74817E-05 

2.72989E-05 

1.77890E-04 

13 

16008.0 

3.74817E-05 

2.72989E-05 

1.77890E-04 

14 

16008.0 

3.74817E-05 

2.72989E-05 

1.77890E-04 

15 

16008.0 

3.74817E-05 

2.72989E-05 

1.77890E-04 

16 

16008.0 

3.74812E-05 

2.72989E-05 

1.82033E-04 

17 

16008.0 

3.74812E-05 

2.72989E-05 

1.87766E-04 

18 

16008.0 

3.74812E-05 

2.72989E-05 

1.87766E-04 

19 

16008.0 

3.74812E-05 

2.72989E-05 

1.87766E-04 

20 

16008.0 

3.74812E-05 

2.72989E-05 

1.87766E-04 

21 

16008.0 

3.74812E-05 

2.72989E-05 

1.91659E-04 

22 

16008.0 

3.74812E-05 

2.72989E-05 

1.82986E-04 

23 

16008.0 

3.74812E-05 

2.72989E-05 

1.78799E-04 

24 

16008.0 

3.74812E-05 

2.72989E-05 

1.78799E-04 

25 

16008.0 

3.74812E-05 

2.72989E-05 

1.78799E-04 

26 

16008.0 

3.74812E-05 

2.72989E-05 

1.78799E-04 

27 

16008.0 

3.74812E-05 

2.72989E-05 

1.78799E-04 

28 

16008.0 

3.74812E-05 

2.72989E-05 

1.93834E-04 

29 

16008.0 

3.74812E-05 

2.72989E-05 

1.93834E-04 

30 

16008.0 

3.74812E-05 

2.72989E-05 

1.93834E-04 

Number 

of 

Average 

Minimum 

Maximum 

Station 

data 

message 

message 

message 

Address 

mess. 

length 

length 

length 

sent 

(  In  bits 

and  Including  overhead  ) 

1 

23.0 

583.39 

70.00 

2422.00 

2 

129.0 

537.10 

70.00 

3366.00 

3 

1145.0 

607.89 

70.00 

3622.00 

4 

1161.0 

580.83 

70.00 

3766.00 

5 

117.0 

559.16 

70.00 

2646.00 

6 

21.0 

596.48 

86.00 

1350.00 

7 

31.0 

520.06 

70.00 

1782.00 

8 

117.0 

590.48 

70.00 

1894.00 

9 

1098.0 

580.35 

70.00 

4134.00 

10 

1120.0 

568.33 

70.00 

3302.00 

11 

119.0 

657.03 

70.00 

2262.00 

12 

20.0 

624.40 

86.00 

1990.00 

13 

28.0 

631.71 

86.00 

1718.00 

14 

128.0 

624.25 

70.00 

2294.00 

15 

1155.0 

565.63 

70.00 

3382.00 

16 

1164.0 

569.78 

70.00 

3238.00 

17 

129.0 

617.97 

70.00 

3382.00 

18 

18.0 

614.00 

150.00 

1798.00 

19 

25.0 

498.80 

86.00 

1926.00 

20 

116.0 

666.14 

86.00 

2694.00 

21 

1128.0 

559.97 

70.00 

4166.00 

22 

1098.0 

577.32 

70.00 

3174.00 

23 

129.0 

596.39 

70.00 

3798.00 

24 

28.0 

490.00 

86.00 

1382.00 

25 

27.0 

592.07 

70.00 

2374.00 

26 

131.0 

548.17 

86.00 

2102.00 

27 

1072.0 

579.55 

70.00 

3222.00 

28 

1051.0 

551.61 

70.00 

3990.00 

29 

125.0 

534.51 

70.00 

2230.00 

30 

22.0 

479.45 

102.00 

1462.00 

Total 

Total 

Total 

Total 

number 

average 

number 

average 

of 

access 

of 

message 

accesses 

delay 

messages 

length 

(seconds) 

(bits) 

480243.0 

3.74814E-05 

12675.0 

575.75 

98 


Average 

Minimum 

Maximum 

Station 

message 

message 

message 

Address 

delay 

delay 

delay 

(seconds) 

(seconds) 

(seconds) 

1 

3.861E-05 

4.381E-06 

1.300E-04 

2 

3.539E-05 

4.739E--06 

1.363E-04 

3 

3.250E-05 

2.176E-06 

1.520E-04 

4 

3.276E-05 

1.580E-06 

1.665E-04 

5 

3.020E-05 

2.384E-06 

1.123E-04 

6 

3.161E-05 

1.189E-05 

7.206E-05 

7 

3.589E-05 

7.298E-06 

7.908E-05 

8 

3.349E-05 

3.368E-06 

9.684E-05 

9 

3.271E-05 

2.369E-06 

1.357E-04 

10 

3.256E-05 

2.086E-06 

1.381E-04 

11 

3.390E-05 

3.397E-06 

9.298E-05 

12 

3.622E-05 

1.433E-05 

7.147E-05 

13 

3.171E-05 

3.383E-06 

7.702E-05 

14 

3.167E-05 

2.831E-06 

8.844E-05 

15 

3.203E-05 

2.213E-06 

1.444E-04 

16 

3.261E-05 

2.325E-06 

1.379E-04 

17 

3.411E-05 

2.369E-06 

1.098E-04 

18 

3.377E-05 

8.017E-06 

7.111E-05 

19 

3.586E-05 

5.729E-06 

9.835E-05 

20 

3.669E-05 

4.709E-06 

1.895E-04 

21 

3.196E-05 

2.116E-06 

1.073E-04 

22 

3.253E-05 

2.444E-06 

1.782E-04 

23 

3.439E-05 

3.636E-06 

1.066E-04 

24 

2.603E-05 

5.305E-06 

4.649E-05 

25 

3.159E-05 

5.648E~06 

9.596E-05 

26 

2.870E-05 

3.368E-06 

7.364E-05 

27 

3.290E-05 

2.176E-06 

1.148E-04 

28 

3.175E-05 

2.265E-06 

1.274E-04 

29 

3.083E-05 

3.487E-06 

9.008E-05 

30 

3.705E-05 

1.283E-05 

8.708E-05 

Total  average  message  delay  was:  3.25021E-05  seconds 

The  normalized  delay  is:  3.21323  (without  overhead) 

The  normalized  delay  is:  2.82257  (with  overhead) 


Total  number  of  complete 

token-passing  cycles  was  16008.00 

The  mean  token-passing  cycle  time  Is  3.748I1E-05  seconds 

The  mean  throughput  was  7.199736  megabits/second 

With  a  bit  rate  of  50.0000  megabits/second 

the  ratio  of  throughput  to  the  bit  rate  Is:  0.143995 

The  mean  efficiency  was  0.211945 


SPIETH  job  terminated  at  lO-OCT-1985  17:53:11.35 

Accounting  Information: 


Buffered  1/0  count: 

53 

Peak  working  set  size: 

Direct  I/O  count: 

70 

Peak  page  file  size: 

Page  faults: 

482 

Mounted  voliimes: 

Charged  CPU  time: 

0  00:00:58.62 

Elapsed  time:  0  00 

-.*  <-  KT.  »v"  ^  ^1  ■  W' 


Appendix  B.  Simulation  Model  Program  Software 

This  appendix  contains  the  Pascal  software  for  the  simulation  model 
program.  The  modules  that  make  up  the  software  are  grouped  according  to 
function  and  placed  Into  seven  files  for  ease  of  editing  and 
configuration  control.  Six  of  the  files  are  then  "Included"  In  the 
seventh  file,  using  the  VAX/VMS  operating  system  Zlnclude  directive,  to 
make  the  complete  program.  The  Zlnclude  directives  are  In  the 
declaration  section  of  the  main  Pascal  module  In  the  file  busslm.pas. 

The  modules  and  what  file  they  are  contained  In  are  listed  below. 

Except  for  the  busslm.pas  file  which  Is  listed  first,  the  other  files 
are  listed  In  their  "Included"  order.  The  modules  within  a  file  are 
listed  In  their  compilation  order.  The  software  follows  this  listing. 


File  Name 

-  busslm.pas 

-  declar.pas 


Module  Name  Module  Number 

main  0.0 

constant,  type,  and  variable  declarations 


-  queue. pas 


pop  2 . 1 . 5 . 1 

out_f ront_queue  2.1.5 

ln_rear_queue  2 . 1 . 4 . 1 


-  stats. pas 

min 

max 

8um_delay 

sum_thruput 

statistics 


2. 1.1.1 
2. 1.1. 2 
3.2 
3.1 
3.0 
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r **************************************************************** 
k  * 

^  DATE;  23  Sep  1985  * 

*  VERSION;  1.3  * 

k  * 

^  TITLE;  bus  simulation  * 

FILENAME;  busslm.pas  * 

*  COORDINATOR;  Jim  Spleth  * 

*  PROJECT;  Avionics  Bus  Simulation  Model  * 

OPERATING  SYSTEM;  VAX/VMS,  Version  4.2  on  VAX-11/782  * 

*  LANGUAGE;  Pascal  * 

*>  USE;  main  pascal  program  * 

*  CONTENTS;  busslm  * 

*  FUNCTION;  simulate  token-passing  bus  * 


****************************************************************) 


(**************************************************************** 
*  * 


DATE:  23  Sep  1985 
VERSION:  1.3 


NAME:  busslm  (main) 

MODULE  NUMBER;  0.0 

DESCRIPTION:  main,  executive  module  for  busslm  program 
PASSED  VARIABLES:  none 
RETURNS:  none 

GLOBAL  VARIABLES  USED:  none 

GLOBAL  VARIABLES  CHANGED:  slm_clock  num_cycle 

total_cyc_tlme  total_thruput  total_eff 
FILES  READ:  none 
FILES  WRITTEN:  none 
MODULES  CALLED:  sel_bus_aetup 
simulate 
statistics 

CALLING  MODULES:  none 


* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 


*  AUTHOR:  Jim  Spleth 

*  HISTORY:  1.3  23  Sep  85 

*  1.2  18  Sep  85 

*  1.1  24  Aug  85 

*  1.0  19  Aug  85 


added  total_cyc_tlme  * 

added  update. pas  Include  file  * 

added  global  thruput  variables  * 

original  * 

****************************************************************) 
program  busslm( Input,  output)  ; 


% Include 
Zlnclude 
%lnclude 
%lnclude 
%lnclude 
Zlnclude 


'declar.pas' 
'queue. pas' 
'stats. pas' 
'update. pas' 
'setup. pas' 
'simulate. pas' 


begin 

slm_clock  :=  0.0  ; 
num_cycle  :=  0.0  ; 
total_thruput  :••  0.0  ; 
total_eff  :=  0.0  ; 
total_cyc_tlme  :■  0.0  ; 

sel_bus_setup  ; 
simulate  ; 
statistics  : 


^4t***«(4c4tAA*4c*4tA*AA**A**4t4t*4t*4c**ii*4i*A*4i4t**4t***A*4c4c*4t**4t*4t4t*A***A*A 
*  * 

*  DATE:  24  Sep  1985  * 

*  VERSION:  1.6  * 

*  * 

*  TITLE:  declarations  for  program  busslm  * 

*  FILENAME:  declar.pas  * 

*  COORDINATOR:  Jim  Spleth  * 

PROJECT:  Avionics  Bus  Simulation  Model  * 

*  OPERATING  SYSTEM:  VAX/VMS,  Version  4.2  on  VAX-11/782  * 

*  LANGUAGE:  Pascal  * 

*  USE:  Zlnclude  file  in  program  busslm  * 

*  CONTENTS:  constant,  type  and  var  * 

*  FUNCTION:  contain  all  declarations  for  program  busslm  * 

*  * 

****************************************************************) 

const  speed_light  ■  3.0e8  ; 

type 

choice  =  (same,  dlff)  ; 

arrival  *  (constant_arr ,  polsson,  contin)  ; 
length_dlstrlb  “  (constant_len,  exp)  ; 

,  control  ■  (dlstrlb,  central)  ; 

token_pass_type  ■  (ascen,  descen,  fixed)  ; 
token_hold_limlt_type  “  (time,  num)  ; 


stats_type 


record 

address  :  integer 


ntim_access  :  r< 
sum_jacces8  :  ti 
mln_access  :  r< 
max_access  ;  ri 
num_messages  : 
sum_mess_len  : 
mln_mes8_len  : 
niax_me88_len  : 
8um_me88_delay 
mln_me88_delay 
max_mes8_delay 


real  ; 
real  ; 
real  ; 
real  ; 

:  real  ; 
:  real  ; 
:  real  ; 
:  real  ; 
y  :  real 
y  :  real 
y  :  real 


end  ;  (*  of  record  *) 

8tats_ptr  ■  " atats  ; 

8tats  =  record 

data  ;  stats_type  ; 
next  :  8tats_ptr  ; 
end  ;  (*  of  record  *) 


mes8age_type 


meaaageptr 


record 

80urce_add  :  integer 
length  :  real  ; 
arr_tlme  :  real  ; 
end  ;  (*  of  record  *) 

mesaage  ; 


message  >  record 

Info  :  me8sage_type  ; 
next_message  :  message_j>tr 
end  j  (*  of  record  *) 

8tation_j)tr  *  “  station  ; 
statlon_type  “  record 

address  :  Integer  ; 
pass_addres8  :  integer  ; 
mess_arr_type  :  arrival  ; 
mes8_arr_rate  :  real  ; 
distance  :  real  ; 
mes8_len_type  :  length_dlstrlb  ; 
mess_len_mean  :  real  ; 
pas8__prop_tlme  :  real  ; 
last_access  :  real  ; 
front_mess_queue  :  message_ptr  ; 
rear_me88_queue  :  message_ptr  ; 
end  ;  (*  of  record  *) 

station  =  record 

attrlb  ;  8tatlon_type  ; 
next_statlon  :  station_ptr 
end  ;  (*  of  record  *) 


front_station,  current_statlon  ; 

station_j)tr 

front_stats,  current_stats  ; 

stats_ptr  ; 

bit_rate, 

prop_f  actor, 

sig_j)rop, 

slg_delay. 

bu8_length, 

stat_delay. 

overhead_bits , 

token_bits. 

blts__per_data_word , 

token_hold_limit , 

min_data_words , 

max_data_words , 

sim_clock. 

slm_stop_tlme , 

total_thruput , 

total_eff , 

total_cyc_time , 

num_cycle , 

statlon_arr_rate , 

station_len_mean 

:  real  ; 

flrst__statlon,  num_statlons,  seed  :  Integer 


station_arr,  statlon_rate, 
statlon_len,  statlon_mean  :  choice  ; 


station_arr_type 

:  arrival  ; 

8 ta 1 1 on_len_t  y pe 

:  length_dlstrib  ; 

bu8_control 

:  control  ; 

token__pass 

;  token_pass_type  ; 

token_hold_type 

:  token_hold_llmlt_type  ; 

calc_pas8_prop_time 

:  boolean  ; 

.V". !;■» .1  ’J'. V  '.VAWAW^ ^ WW g H.’  •■  •!.■>;■--  ■  ft* ;L" .m ft" l« .■  ^»  .1  ■  J";-.- » 


^4tA******4t****4c*4t*4(*4t*4t****A*A****A*AA*4tAA*A*A*A**4t*4r4r*ilr********it 


* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 


DATE:  18  Aug  1985 
VERSION:  1.0 

TITLE:  queue  (linked  list)  related  procedures 

FILENAME:  queue. pas 

COORDINATOR:  Jim  Spleth 

PROJECT:  Avionics  Bus  Simulation  Model 

OPERATING  SYSTEM:  VAX/VMS,  Version  4  on  VAX-11/782 

LANGUAGE:  Pascal 

USE:  %lnclude  file  for  busslm  program 
CONTENTS :  pop 

out_front_queue 

ln_rear_queue 

FUNCTION:  procedures  for  queue  (linked  list)  operations 


* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 


Ic***************************************************************'^ 


•k  k 


DATE;  18  Aug  1985 
VERSION:  1.0 


* 

* 

* 


* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 


NAME :  pop 

MODULE  NUMBER:  2. 1.5.1 

DESCRIPTION:  removes  first  message  In  queue  (linked  list) 
PASSED  VARIABLES:  list  -  pointer  to  front  of  list 
RETURNS:  list 

GLOBAL  VARIABLES  USED:  none 

GLOBAL  VARIABLES  CHANGED:  none 

FILES  READ :  none 

FILES  WRITTEN:  none 

MODULES  CALLED:  none 

CALLING  MODULES:  out_front_queue 


* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 


*  AUTHOR:  Jim  Spleth  * 

*  HISTORY:  Adapted  from  Dale  and  Orshallck,  1983:443  * 

k  k 


kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk'^ 


procedure  pop(var  list  :  message_ptr  )  ; 


var  ptr  :  message_j>tr  ; 
begin 

ptr  :=  list  ; 

list  list' .next_message  ; 
dlspose(ptr) 
end  ; 
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(^h*************************************************************** 
k  k 

*  DATE:  18  Aug  1985  * 

*  VERSION:  1.0  * 


*  NAME:  out_front_queue  * 

*  MODULE  NUMBER:  2.1.5  * 

*  DESCRIPTION:  removes  message  from  front  of  queue  (linked  * 

*  list)  and  checks  for  empty  queue  * 

*  PASSED  VARIABLES:  front  -  pointer  to  front  of  list  * 

*  rear  -  pointer  to  rear  of  list  * 

*  RETURNS:  front,  rear  * 

*  GLOBAL  VARIABLES  USED:  none  * 

*  GLOBAL  VARIABLES  CHANGED:  none  * 

*  FILES  READ:  none  * 

*  FILES  WRITTEN:  none  * 

*  MODULES  CALLED:  pop  * 

*  CALLING  MODULES:  dlst_algor  * 

*  * 

*  AUTHOR:  Jim  Spleth  * 

*  HISTORY:  Adapted  from  Dale  and  Orshallck,  1983:454  * 

*  * 
k*kk***kk**kkkk*k**kk*kkkkkkkk*k*****k*kkk*kk*kk*k*k*kkkkk*k**kk'^ 

procedure  out_front_queue(var  front,  rear  :  message__ptr  )  ; 
begin 

If  (front  =  nil) 

then  wrlteln( 'queue  is  empty') 
else 

begin 

pop(  front  )  ; 
if  (front  *  nil) 
then  rear  :*  nil 


DATE:  18  Aug  1985 
VERSION:  1.0 


NAME :  ln_rear_queue 
MODULE  NUMBER:  2. 1.4.1 

DESCRIPTION:  Inserts  element  at  rear  of  queue 

PASSED  VARIABLES:  front,  rear,  element 

RETURNS;  front,  rear 

GLOBAL  VARIABLES  USED:  none 

GLOBAL  VARIABLES  CHANGED;  none 

FILES  READ:  none 

FILES  WRITTEN:  none 

MODULES  CALLED:  none 

CALLING  MODULES:  calc  next  arr  and  len 


AUTHOR:  Jim  Spleth 

HISTORY:  Adapted  from  Dale  and  Orshallck,  1983:454 


* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 


A  A  4r  4c  A  4c  A  A  4r  A  A  A  :1k  A  4r  4c  A  A  4c  4r  4t  4c  A  A  iHc  4r  A  A  4;  4ic  Ik  A  4t  A  A  A  ilr  A  A  it  A  A  il;  A  it  ilr  A  ilr  4riAr  A  4r  4lMlr  A  ^ 

procedure  ln_rear_queue(  var  front,  rear  :  message_ptr  ; 

var  one  mess  :  message  type  )  ; 


var 


ptr  ;  message_ptr  ; 


begin 

new(ptr)  ; 

ptr'. info  :••  one_mess  ; 
ptr' .next_message  ;■  nil  ; 
if  rear  «  nil 
then 

begin 

rear  :*  ptr  ; 
front  ;=  ptr  ; 
end 
else 

begin 

rear'. next  message  :*  ptr  ; 


* 
* 
* 
* 
* 
* 
* 
* 


* 

* 

* 

* 

* 

* 

* 

* 


DATE:  24  Sep  1985 
VERSION:  1.7 

TITLE:  statistics 
FILENAME:  stats. pas 
COORDINATOR:  Jim  Spleth 
PROJECT:  Avionics  Bus  Simulation  Model 


it***************************************************************'^ 


^  •k'kic'kit'k’kitikicit'k'kititicitic'kicitit’kic'k'kifif'k'kiciticitititit'kit'kicrk’kitit'k'kicic’k'k’k'kic'k’k'k'kicic'kic'k'k 

< 

ic 
it 
it 
* 
* 
* 
* 
* 
* 
A 
A 
A 
A 
A 
A 
A 
A 
A 
A 
A 


A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 


DATE:  18  Aug  1985 
VERSION:  1.0 

NAME:  min  (function) 

MODULE  NUMBER:  2. 1.1.1 

DESCRIPTION:  picks  mlnlmxun  of  two  real  numbers 
PASSED  VARIABLES:  reall  and  real2 
RETURNS:  mimlmum  of  the  two 
GLOBAL  VARIABLES  USED:  none 
GLOBAL  VARIABLES  CHANGED:  none 
FILES  READ:  none 
FILES  WRITTEN:  none 
MODULES  CALLED:  none 
CALLING  MODULES:  update_access_8tats 
update_message__stats 
update_deiay_stat8 
AUTHOR:  Jim  Spieth 
HISTORY: 


AAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA^ 

function  min  (reall,  real2  :  real  )  :  real  ; 
begin 

if  reall  >  real2 

then  min  :=  real2 
else  min  :•  reall 

end  ; 


I 


r  •  fc* 

iV-i 


A 

OPERATING  SYSTEM:  VAX/VMS,  Version  4.2  on  VAX-11/782 

* 

A 

LANGUAGE:  Pascal 

* 

A 

USE:  %lnclude  file  for  busslm  program 

* 

A 

CONTENTS:  min 

* 

A 

max 

* 

A 

sum_delay 

* 

i»‘-  *  j 

A 

sum  thruput 

* 

A 

statistics 

* 

A 

FUNCTION:  perform  statistics  operations 

* 

•  v-v 

U 


u 


u 


'■\y 

;v--: 
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DATE:  18  Aug  1985 
VERSION:  1.0 


NAME:  max  (function) 

MODULE  NUMBER:  2. 1,1. 2 
DESCRIPTION:  picks  maximum  of  two  reals 
PASSED  VARIABLES:  reall ,  real2 
RETURNS:  maximum  of  the  two 
GLOBAL  VARIABLES  USED:  none 
GLOBAL  VARIABLES  CHANGED:  none 
FILES  READ:  none 
FILES  WRITTEN:  none 
MODULES  CALLED:  none 
CALLING  MODULES:  update_access_stats 
update_message_stats 
update_delay_stats 
AUTHOR:  Jim  Spleth 
HISTORY: 


* 

A 

* 

* 

* 

* 

* 

* 

* 

* 

9t 

* 

* 

* 

* 

* 

* 

A 

* 

* 


function  max  (reall,  real2  :  real  )  :  real  ; 


begin 

If  reall  >  real2 
then  max  :=  reall 
else  max  :»  real2 


DATE:  18  Sep  1985 
VERSION:  1.1 


NAME :  suin_delay 
MODULE  NUMBER:  3,2 

DESCRIPTION:  calculates  and  prints  message  delay  values 
PASSED  VARIABLES:  none 
RETURNS:  nothing 

GLOBAL  VARIABLES  USED:  num_stations ,  front_stats 

front_station,  bit_rate 

GLOBAL  VARIABLES  CHANGED:  current_stats  current_station 

FILES  READ :  none 

FILES  WRITTEN:  none 

MODULES  CALLED:  none 

CALLING  MODULES:  statistics 


AUTHOR:  Jim  Spieth 
HISTORY: 

1.1  18  Sep  85  added  2nd  form  of  normalized  delay 

1.0  30  Aug  85  original 


* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

•k 

k 

k 

k 

k 

k 

k 

k 

k 

k 

k 


kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk'^ 

procedure  sum_delay( total_num_mess ,  total_ave_mess_len  :  real)  ; 


var 


h,  one,  yes  :  Integer  ; 


total_sum_delay,  ave_delay, 

total_ave,  full_delay_ratlo,  delay_ratio  :  real  ; 

begin 
one  :=  0  ; 

total_sum_delay  :=  0,0  ; 
current_stats  :=  front_stats  ; 
current_station  :=  front_station  ; 
case  station_arr  of 

same  :  case  station_arr_type  of 

constant_arr  :  case  station_rate  of 
diff  :  yes  :=  1  ; 
same  :  If  station_arr_rate  =  0.0 
then  yes  :*  0 
else  yes  :=  1 
end  ;  (*  of  case  *) 

poisson  :  yes  :*  1  ; 
contin  :  yes  :=  0  ; 
end  ;  (*  of  case  *) 
diff  :  yes  :=  1  ; 
end  ;  (*  of  case  *) 


If  yes  “  1  then 
begin 

for  h  ;*  1  to  num_station8  do 
begin 

If  current_8tation" .attrlb.mes8_arr_type  <>  contln 
then 

If  ((current_8tatlon* .attrlb.mess_arr_type  <>  constant_arr)  or 
(current  station'"  .attrlb. mess  arr  rate  <>  0.0  )) 


then 

begin 

If  one  *  0  then 
begin 
page  ; 
wrltelnC ' 

Average 

Minimum 

Maximum ' )  ; 

wrltelnC ' Station 

message 

message 

message ' )  ; 

wrltelnC 'Address 

delay 

delay 

delay'  )  ; 

wrltelnC ' 

(seconds) 

(seconds) 

(seconds) ' ) ; 

wrlteln  ; 
end  ; 

total_sum_delay  :=* 

total_sum_delay  + 

current  stats '".data. sum  mess_delay  ; 


If  current_stata' .data.num_messages  =  0.0 
then  ave__delay  0.0 

else  ave_delay  :■  current_stats'"  .data.8um_mess_delay  / 

current_stat8" .data.num_mes8ages  ; 
writeln(current_stats' .data.address:4,  ' 
ave_delay:10,  ’ 

current__8tats^ .data.mln_mess_delay:10,  ' 
current^stats^ .data.max_mes8_delay;10  )  ; 
one  :■  one  +  1  ; 

current_8tatlon  ;•  current_statlon'"  .next_statlon  ; 
current__stats  :*  current_stats'"  .next  ; 
end  ; 

end  ;  (*  for  *) 

If  one  >  0  then 
begin 

total_ave  total_sum_delay  /  total_num_me9s  ; 

delay_ratlo  total_ave  /  ((total_ave_me8s_len  -  overhead_blts)  / 

blt_rate)  ; 

full_delay_ratlo  ;■  total_ave  /  (total_ave_me8s_len  /  blt_rate)  ; 
wrlteln  ; 

wrltelnC 'Total  average  message  delay  was:  total_ave,  '  seconds'); 

wrlteln  ; 

wrltelnC 'The  normalized  delay  Is:  delay_ratlo:15:5, 

'  (without  overhead)')  ; 
wrlteln  ; 

wrltelnC 'The  normalized  delay  Is:  full_delay_ratlo:15:5, 

'  (with  overhead)')  ; 
wrlteln  ; 
end  ; 


**************************************************************** 


DATE:  23  Sep  1985 
VERSION:  1.1 

NAME :  suni_thruput 
MODULE  NUMBER:  3.1 

DESCRIPTION:  calculates  and  prints  throughput  values 
PASSED  VARIABLES:  none 
RETURNS:  nothing 

GLOBAL  VARIABLES  USED:  num_cycle,  total_thruput 

total_eff,  total_cyc_time 
GLOBAL  VARIABLES  CHANGED:  none 
FILES  READ:  none 
FILES  WRITTEN:  none 
MODULES  CALLED:  none 
CALLING  MODULES:  statistics 


AUTHOR:  Jim  Spieth 
HISTORY:  1.1  23  Sep  85  added  total_cyc_time  &  ave_cyc_time  * 
1.0  23  Aug  85  original  * 


****************************************************************) 
procedure  sum_thruput  ; 


var 


ave_thruput,  ave_eff,  ave_cyc_tlme , 
mod_bit__rate,  thruput_ratlo 


:  real  ; 


begin 

mod_bit_rate  :=  bit_rate  /  1.0e6  ; 

ave_thruput  :=  (total_thruput  /  num_cycle)  /  1.0e6  ; 
ave_eff  :*  total_eff  /  num_cycle  ; 
ave_cyc_time  :=  total_cyc_time  /  num_cycle  ; 
thruput_ratio  :=  ave_thruput  /  mod_bit_rate  ; 
page  ; 

writeln( 'Total  number  of  complete  ')  ; 

wrlteln( '  token-passing  cycles  was',  num_cycle:14;2)  ; 

writeln  ; 

writelnC'The  mean  token-passing  cycle  time  is  ',  ave_cyc_time , 

'  seconds')  ; 
writeln  ; 

writelnCThe  mean  throughput  was',  ave_thruput :  12 :6 , 

'  megabits/second')  ; 
writeln  ; 

wrlteln( 'With  a  bit  rate  of,  mod_bit_rate:10:4, '  megabits/second'); 
write  ('  the  ratio  of  throughput  to  the  bit  rate')  ; 
wrltelnf  is;',  thruput_ratlo;12:6)  ; 
writeln  ; 

writelnCThe  mean  efficiency  was',  ave_eff :12:6)  ; 
writeln  ; 


(^It*************************************************************** 
*  * 

DATE:  27  Sep  1985  * 

VERSION:  1.3  * 


NAME:  statistics 
MODULE  NUMBER:  3.0 

DESCRIPTION:  calculates  and  prints  station  and  sununary 
statistics 

PASSED  VARIABLES:  none 
RETURNS :  nothing 

GLOBAL  VARIABLES  USED:  frontjstats 
GLOBAL  VARIABLES  CHANGED:  current_stats 
FILES  READ:  none 
FILES  WRITTEN:  none 

MODULES  CALLED:  sum_thruput  sum_delay 

CALLING  MODULES:  busslm  (main) 

AUTHOR:  Jim  Spleth 


* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 


* 

HISTORY: 

* 

* 

1.3 

27  Sep 

85 

Improved  headings 

* 

* 

1.2 

30  Aug 

85 

added  sum_delay  call 

* 

* 

1.1 

23  Aug 

85 

added  sum_thruput  call 

* 

* 

1.0 

19  Aug 

85 

original 

* 

****************************************************************) 
procedure  statistics  ; 


var 

1  :  Integer  ; 

total_num_access ,  total_access , 
ave_access , 

total_num_mess ,  total_mess_len , 
ave_mess_len , 

total_ave_access ,  total_ave_mess_len 


:  real  ; 


begin 

total_num_access  :«  0.0  ; 
total_access  :■  0.0  ; 
ave_access  :■  0.0  ; 
total_num_mess  :»•  0.0  ; 
total_mess_len  :*  0.0  ; 
ave_mess_len  :=  0.0  ; 
total_ave_access  :*  0.0  ; 
total_ave  mess_len  0.0  ; 


page  ; 
writelnC ’ 

Number 

Average 

Minimum 

Maximum ' ) ; 

writeln( ' Station 

of 

access 

access 

access'); 

wrlteln( 'Address 

access 

delay 

delay 

delay' ) ; 

wrlteln( ' 
writeln  ; 

(seconds) 

(seconds) 

(seconds) ' ) 

current  stats  :■  front  stats  : 


for  1  1  to  num_statlons  do 

begin 

total_num_access  :*  total_nuin_access  + 

current_stats^ .data.num_acces8  ; 
total_access  :*  total_access  current_stats'‘ .data.suin_access  ; 
ave_access  :*  current_atats“ .data.sum_acces8  / 

(current_8tats'' .data.num_acces8  -  1.0  )  ; 
wrlteln(current_8  tats  * . data . address : 4 , 

current_8tats" .data.nuin_access:13:l, '  ave_access, 

'  ’  ,current_8tat8“  .data.inln_access, 

'  current_stats".data.max_access  )  ; 
current_stats  :■  current_stats' .next  ; 
end  ; 
page  ; 

writelnC '  Number  ' )  ; 

wrlteln( '  of  Average  Minimum  Maximum  ' ) 

writelnC 'Station  data  message  message  message  ') 

writelnC 'Address  mess.  length  length  length  ') 

writelnC '  sent  C  in  bits  and  including  overhead  )  ' ) 

wrlteln  ; 

current_stats  front_stat8  ; 
for  i  ;*  1  to  num_stations  do 
begin 

total_num_mess  j=  total_num_mess  +  current_stats'' .data.numjmessages 
total_mess__len  ;=  total_mess_len  +  current_stat8'' .data.8tam_mess_len 
if  current_stat8* .data.numjnessages  ■  0.0 
then  ave_mess_len  ;■  0.0 

else  ave_mess_len  :■  current_stats^ .data.sum_mess_len  / 

current_stats" .data.num_messages  ; 
writelnCcurrent_stats^ . data .address : 4 , 

current_stats* .data.num_messages:13:l,  ave_mess_len:14:2, 
current_stats^ . data .mln_mess_len: 14 : 2 , 
current_stats'' .data.max_mess_len;14:2  )  ; 
current_stats  :=  current_stats' .next  ; 
end  ; 

total_ave_access  :*  total_access  /  Ctotal_num_access  -  num_8tations)  ; 

total_ave_mess_len  :=  total_mess_len  /  total_num_mess  ; 

wrlteln  ; 

wrlteln  ; 

wrlteln  ; 


writelnC ' 

Total 

Total 

Total 

Total 

’) 

writelnC ' 

number 

average 

number 

average 

’) 

writelnC ' 

of 

access 

of 

message 

’) 

writelnC ' 

accesses 

delay 

messages 

length 

') 

writelnC ' 

C seconds) 

Chits) 

') 

wrlteln  ; 

writelnCtotal__num_access;10;l,  '  total_ave_acce8s , 

total_num_mess:12:l,  total_ave_me8s_len:14:2  )  ; 

sum_delayCtotal_num_mes8,  total_ave_mess_len)  ; 
sum_thruput  ; 

end  ;  c****  statistics  ****) 


f^**************************************************************** 
k  * 

*  DATE:  23  Sep  1985  * 

*  VERSION:  1.1  * 


*  TITLE:  update  statistics  * 

*  FILENAME:  update. pas  * 

*  COORDINATOR:  Jim  Spleth  * 

*  PROJECT:  Avionics  Bus  Simulation  Model  * 

*  OPERATING  SYSTEM:  VAX/VMS,  Version  4.2  on  VAX-11/782  * 

*  LANGUAGE:  Pascal 

*  USE:  Zlnclude  file  for  busslm  program 

*  CONTENTS;  update_acceas_atats 

*  update_message_stats 

*  update_delay_atats 

*  update_thruput_stats 

*  FUNCTION:  perform  data  collection  and  updates 

* 


DATE:  31  Aug  1985 
VERSION:  1.0 


* 
* 
* 
* 

NAME:  update_access_stats  * 

MODULE  NUMBER:  2.1.1  * 

DESCRIPTION:  updates  access  delay  times  for  each  station  * 
PASSED  VARIABLES:  time  of  station's  last  access  * 

RETURNS:  time  of  this  access  ~  slm_clock  * 

GLOBAL  VARIABLES  USED:  slm_clock  current_stats  * 

GLOBAL  VARIABLES  CHANGED:  none  * 

FILES  READ:  none  * 

FILES  WRITTEN:  none  * 

MODULES  CALLED:  min  max  * 

* 

* 
* 
* 
* 


CALLING  MODULES:  dlst_algor  cent_algor 

AUTHOR:  Jim  Spleth 
HISTORY: 


procedure  update_access_stats(  var  last_access  :  real  ; 

pass_cyc  :  Integer  )  ; 


var 

current_delay 


real 


begin 

current_stat8 *.data.num_access  :■  current_stats".data.num  access 

+  1.0  ; 

If  pass_cyc  >  1 
then 
begin 

current_delay  :■  slm_clock  -  last_acce88  ; 

current_stats '.data.sum_access  :■  current_8tats*.data.sum_access 

+  current_delay  ; 

current_stats ".data.mln^access  :«  mln( 

current_stats '.data .mln_access , 
current_delay  )  ; 

current_stats '.data.max_access  :••  max( 

current_stats ' . data .max_access , 
current_delay  )  ; 

end  ; 

last  access  slm  clock  : 


*  * 

*  DATE:  21  Aug  1985  * 

*  VERSION:  1.0  * 

*  * 

*  NAME:  update_message_stats  * 

*  MODULE  NUMBER:  2.1.2  * 


DESCRIPTION:  updates  station's  message  statistics 
PASSED  VARIABLES:  message  length 
RETURNS:  nothing 

GLOBAL  VARIABLES  USED:  current_stats 
GLOBAL  VARIABLES  CHANGED:  none 
FILES  READ:  none 
FILES  WRITTEN:  none 


*  MODULES  CALLED:  min  max  * 

*  CALLING  MODULES:  dlst_algor  cent_algor  * 

*  * 

*  AUTHOR:  Jim  Spleth  * 

*  HISTORY:  * 

*  * 


procedure  update_message_scats  (  mess_len  :  real  )  ; 


begin 

current_stats  ^.data.num_mes8ages  :•  current_s tats  '.data .num_me8sages 

+  1.0  ; 

current_stat3 *.data.sum_mess_len  :•  current_8tats''.data.8um_mess_len 

+  mes8_len  ; 

current_stats ‘.data.min_me8s_len  :•  min( 

curr  ent_8  ta  t  s  “ .  da  ta .  min_mes8_len , 
me8S_len  )  ; 

current_8tats ^.data.max_me8s_len  :*>  max( 

current_8tat8 " . data .max_me8S_len , 
mess  len  )  ; 


DATE:  30  Aug  1985 
VERSION:  1.0 


NAME:  update_jlelay_stats 
MODULE  NUMBER:  2.1.3 

DESCRIPTION:  updates  station's  message  delay  statistics 
PASSED  VARIABLES:  message  arrival  time 
RETURNS:  nothing 

GLOBAL  VARIABLES  USED:  current_stats  sim_clock 

GLOBAL  VARIABLES  CHANGED:  none 

FILES  READ :  none 

FILES  WRITTEN:  none 

MODULES  CALLED:  min  max 

CALLING  MODULES:  dlst_algor  cent_algor 


* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 


AUTHOR:  Jim  Spleth 
HISTORY: 


procedure  update_delay_stats  (  arr_tlme  :  real  )  ; 


var 


delay  :  real  ; 


begin 

delay  :*  slm_clock  -  arr_time  ; 
current_stats^ .data.8um_mess_delay  :■ 

current_stats^ .data.sum_mess_delay  +  delay  ; 
current_stats' .data.min_mes8_delay  :» 

min(current_stats'' .data.min_mess_delay ,  delay  )  ; 
current_stats‘'  .data.max_mes8_delay 

max(current  stats* .data. max  mess  delay,  delay  )  ; 


DATE:  23  Sep  1985 
VERSION:  1.1 


NAME:  update_thruput_stats 
MODULE  NUMBER:  2.1.6 

DESCRIPTION:  calculates  and  updates  data  for  throughput 
calculations 

PASSED  VARIABLES:  token-passing  cycle  time  -  cyc_tlme 
sum  of  data  bits  -  sum_data 
sum  of  overhead  bits  -  sum_over 
RETURNS:  sum_data  and  sum_over  set  to  zero 
GLOBAL  VARIABLES  USED:  none 
GLOBAL  VARIABLES  CHANGED:  total_thruput 

total_cyc_tlme 

FILES  READ :  none 
FILES  WRITTEN:  none 
MODULES  CALLED:  none 

CALLING  MODULES:  dl8t_algor  cent_algor 


total_eff 

num_cycle 


AUTHOR:  Jim  Spleth 
HISTORY: 

23  Sep  85 
23  Aug  85 


1.1 

1.0 


added  total_cyc_tlme 
original 


* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 


procedure  update_thruput_stats(cyc_tlme  :  real  ;  var  stimjdata, 
sum  over  :  real  )  ; 


var 

eff, 

thruput  :  real  ; 

begin 

num_cycle  num_cycle  +1.0  ; 

thruput  :*  s\im_data  /  cyc_tlme  ; 

eff  :■  sum_data  /  (sum_data  +  sum_over)  ; 

total_thruput  :*  total_thruput  +  thruput  ; 

total_eff  :••  total_eff  +  eff  ; 

total_cyc_tlme  :*  total_cyc_tlme  +  cyc_tlme  ; 

sum_data  :■  0.0  ; 

sum  over  0.0  ; 


^  4r  *  ^  4c  4t  iHc  4c  4c  *  A  4r  :ll;  ilk  *ilir  A  41;  A  lit  lA;  A  K  ilr  ilriHr  4r  K  K  «r  A  *  K  air  *  *  A  X  #r  * 

A  A 

*  DATE;  24  Sep  1985  * 

*  VERSION:  3.1  * 

*  * 

*  TITLE:  Setup  * 

*  FILENAME:  setup. pas  * 

*  COORDINATOR:  Jim  Spieth  * 

*  PROJECT:  Avionics  Bus  Simulation  Model  * 

*  OPERATING  SYSTEM:  VAX/VMS,  Version  4.2  on  VAX-11/782  * 

*  LANGUAGE:  Pascal  * 

*  USE:  %lnclude  file  for  program  busslm  * 

*  CONTENTS:  mth$random  * 

*  bus_data_lnput  * 

*  statlon_data_lnput  * 

*  calc_arr_and_len  * 

*  calc_flrst_arr_and_len  * 

*  lnlt_stats  * 

*  calc_token_jprop_delays  * 

*  sel_bu8_setup  * 

*  FUNCTION:  setup  modules  for  bus  configuration  * 

*  * 


^ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
*  * 

*  DATE;  7  Sep  1985  * 

*  VERSION:  1.0  * 

*  * 

*  NAME:  mth$random  (DEC  run-time  library  function)  * 

*  MODULE  NUMBER;  1.3. 1.1  * 

*  DESCRIPTION:  uniform  random  number  generator  * 

*  PASSED  VARIABLES:  seed  * 

*  RETURNS:  random  number  * 

*  GLOBAL  VARIABLES  USED;  none  * 

*  GLOBAL  VARIABLES  CHANGED:  none  * 

*  FILES  READ:  none  * 

*  FILES  WRITTEN:  none  * 

*  MODULES  CALLED:  none  * 

*  CALLING  MODULES:  calc_arr_and_len  * 

A  A 

*  AUTHOR:  Digital  Equipment  Corp.  * 

*  HISTORY:  * 


AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA^ 

[external .asynchronous]  function  mth$random  (var  seed  :  Integer  ) 
:  real  ;  extern  ; 


.V ,% 


A  4e 


DATE:  24  Sep  1985 
VERSION:  2.1 


* 

* 

* 


NAME:  bus_data_input 
MODULE  NUMBER:  1.1 

DESCRIPTION:  reads  In  bus  attributes  (data) 

PASSED  VARIABLES:  none 
RETURNS:  nothing 
GLOBAL  VARIABLES  USED:  none 
GLOBAL  VARIABLES  CHANGED:  seed  num_stations  f irst_station* 
bit_rate  prop_factor  bus_length  stat_delay  * 

bus_control  token_pass  token_hold_type  token_hold_limit* 
statlon_arr  station_arr_type  8tation_rate  station_arr_rate* 
statlon_len  statlon_len_type  statlon_mean  statlon_len_mean* 
token_blts  overhead_blts  blts_per_data_word  * 

min_data_words  max_data_word8  slm_stop_time  * 

FILES  READ:  Input  * 

FILES  WRITTEN:  none  * 

MODULES  CALLED:  none  * 

CALLING  MODULES:  sel_bus_setup  * 


AUTHOR:  Jim  Spieth 
HISTORY: 


2.1 

2.0 

1.0 


24  Sep  85 
26  Aug  85 
20  Aug  85 


added  token_hold_type 

added  enumerated  reads  and  cases 

original 


* 

* 

* 

* 

* 

* 


procedure  bus_data_input  ; 


var 


k,  1,  m  :  Integer  ; 


begin 

readln(seed)  ; 

readln(num_stations ,  first_station,  bit_rate  )  ; 
readlnC prop_f actor ,  bus_length,  stat_delay  )  ; 
readln(k,  1,  m,  token_hold_limit  )  ; 
case  k  of 

0  :  bus_control  :*  dlstrlb  ; 

1  :  bus_control  :*■  central  ; 
end  ;  (*  case  *) 

case  1  of 

0  :  token__pass  :*•  ascen  ; 

1  :  token_pass  :*■  descen  ; 

2  :  token_jpass  :*  fixed  ; 

end  ;  (*  of  case  *) 

case  m  of 

0  :  token_hold_type  :■  time  ; 

1  :  token_hold_type  :■  num  ; 
end  :  (*  of  case  *) 


readln(k,  1,  m,  station_arr_rate  )  ; 
case  k  of 

0  :  statlon_arr  :*•  same  ; 

1  :  statioii_arr  ;=  dlff  ; 
end  ;  (*  of  case  *) 

case  1  of 

0  :  station_arr_type  constant_arr  ; 

1  :  station_arr_type  :=  polsson  ; 

2  ;  statlon_arr_type  :=  contln  ; 

end  ;  (*  of  case  *) 

case  m  of 

0  :  station_rate  :=  same  ; 

1  ;  station_rate  ;=  dlff  ; 
end  ;  (*  of  case  *) 

readln(k,  1,  m,  statlon_len_mean  )  ; 
case  k  of 

0  :  statlon_len  :■  same  ; 

1  :  statlon_len  ;•  dlff  ; 
end  ;  (*  of  case  *) 

case  1  of 

0  :  statlon_len_type  :=  constant_len  ; 

1  :  statlon_len_type  :=  exp  ; 
end  ;  (*  of  case  *) 

case  m  of 

0  :  statlon_mean  :=  same  ; 

1  ;  statlon_mean  :*  dlff  ; 
end  ;  (*  of  case  *) 

readln(token_blts ,  overhead_blts,  blt8_j>er_data_word  ) 
readln(mln_data_words ,  max_data_words  )  ; 
readln(slm_stop_tlme  )  ; 

[  .  (****  bus_data_lnput  ****) 


DATE:  13  Sep  1985 
VERSION:  1.2 


NAME:  station_data_input 
MODULE  NUMBER:  1.2 

DESCRIPTION:  reads  In  station  attributes  (data) 

PASSED  VARIABLES:  none 
RETURNS:  nothing 

GLOBAL  VARIABLES  USED:  front  station  current  station 


statlon_len 
statlon_len_type 
statlon_mean 
s  t a  t lon_len_mean 
blts_per_data_word 


statlon_arr 
statlon_arr_type 
statlon_rate 
statlon_arr_rate 
calc_pass_prop_tlme 

GLOBAL  VARIABLES  CHANGED:  f ront_statlon  current  station 

calc_pas  s_prop_t  Ime 

FILES  READ:  Input 
FILES  WRITTEN:  none 
MODULES  CALLED:  none 
CALLING  MODULES:  sel_bus_setup 


AUTHOR:  Jim  Spleth 
HISTORY:  1.2  13  Sep  85 

1.1  27  Aug  85 

1.0  18  Aug  85 


* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 


* 

added  calc_pass_j)rop_tlme  * 

added  station  case  statements  * 

original  * 

* 


procedure  statlon_data_lnput  ; 


var  temp_statlon  :  statlon_type  ; 
ptr  :  statlon_ptr  ; 
h,  1,  j,  k  :  Integer  ; 

begin 

wrltelnC station  data  Input  module')  ; 
readln(  h  )  ; 

If  h  =  0 

then  calc_pass_prop_tlme  :=  false 
else  calc_pass_prop_tlme  :=  true  ; 
for  1  :»  1  to  num_statlons  do 
begin 

If  calc_pass_prop_tlme 
then 

readlnC  temp_statlon . address , 

temp_statlon.pass_address, 
temp_statlon. distance  ) 

else 

readln(temp_statlon. address , 

temp_statlon.pass_address, 

temp_statlon .distance , 

temp  station. pass  prop  time  )  ; 


case  statlon_arr  of 
same  :  begin 

temp_statlon.mess_arr_type  :=  station_arr_type  ; 
case  station_rate  of 

same  :  temp_station.mess_arr_rate  :=  statlon_arr_rate 
dlff  :  readln(temp_statlon.mess_arr_rate)  ; 
end  ;  (*  of  case  *) 
end  ; 
dlff  ;  begin 

readln(  j,  temp_statlon.mess_arr_rate  )  ; 
case  j  of 

0  :  temp_statlon.mess_arr_type  :=  constant_arr  ; 

1  :  temp_statlon.mess_arr_type  :=•  polsson  ; 

2  :  temp_statlon.mess_arr_type  :=  contln  ; 

end  ;  (*  of  case  *) 

end  ; 

end  ;  (*  of  case  *) 

case  statlon_len  of 
same  :  begin 

temp_statlon.mess_len_type  :=  statlon_len_type  ; 
case  statlon_mean  of 

same  :  temp_statlon.mess_len_mean  :=  statlon_len_mean 
dlff  :  readln(temp_statlon.mess_len_mean)  ; 
end  ;  (*  of  case  *) 

end  ; 
dlff  :  begin 

readln(k,  temp_statlon.mess_len_mean  )  ; 
case  k  of 

0  :  temp_statlon.mess_len_type  :=  constant_len  ; 

1  ;  temp_statlon.mess_len_type  :=  exp  ; 
end  ;  (*  of  case  *) 

end  ; 

end  ;  (*  of  case  *) 

temp_statlon.mess_len_mean  :•  temp_statlon.mess_len_mean  * 

blts_per_data_word  ; 
temp_statlon.last_access  :■=  0.0  ; 
temp_statlon.front_me8S_queue  :=  nil  ; 
temp_statlon.rear_mess_queue  :=  nil  ; 
new(ptr)  ; 

If  1  =  1 

then  front_statlon  :*  ptr 

else  current_statlon" .next_statlon  :•  ptr  ; 
ptr'.attrlb  :=  temp_statlon  ; 

If  1  “  num_statlons 

then  ptr* .next_statlon  :=  front_statlon 
else  ptr* .next_statlon  ;=  nil  ; 
current_statlon  :=  ptr  ; 
end  ; 

(****  statlon_data_lnput  ****) 


(^h*************************************************************** 


* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 


DATE:  7  Sep  1985 
VERSION:  2.0 


* 
* 
* 
* 

NAME ;  calc_arr_and_len  * 

MODULE  NUMBER:  1.3.1  * 

DESCRIPTION:  calculates  arrival  time  and  length  of  a  new  * 
message  for  a  station  * 

PASSED  VARIABLES:  station  arrival  type  and  rate,  * 

station  length  distribution  type  and  mean* 
RETURNS:  message  arrival  time  and  length  * 

GLOBAL  VARIABLES  USED:  sim_clock  seed  * 

bits_j>er_data_word  mln_data_words  max_data_words  * 
GLOBAL  VARIABLES  CHANGED:  none  * 

FILES  READ:  none  * 

FILES  WRITTEN:  none  * 

MODULES  CALLED:  none  * 

CALLING  MODULES:  calc_flrst_arr_and_len  * 

* 

AUTHOR:  Jim  Spleth  * 

HISTORY:  * 

2.0  updated  dummy  calculations  to  real  ones  * 

1.0  20  Aug  85  dummy  constant,  Poisson  &  exp  calcs  * 


procedure  calc_arr_and_len(arr_type  :  arrival  ; 

arr_rate  :  real  ; 
len_type  :  length_jdistrib  ; 
len_mean  :  real  ; 
var  arrival_time  :  real  ; 
var  mes8age_len  :  real  )  ; 


var  length  :  Integer  ; 


begin 

case  arr_type  of 

constant_arr  ;  begin 

If  arr_rate  «  0.0 

then  arrlval_tlme  ;=  0.0 

else  arrival_time  :»  sim_clock  +  (1.0  /  arr_rate) 
end  ; 

polsson  :  arrival_time  :=  sim_clock  - 

((1.0  /  arr_rate)  *  ln(mth$random(seed)))  ; 
contin  :  arrival_time  :=  0.0  ; 
end  ;  (*  of  case  *) 


case  len_type  of 

constant_len  :  message_len  :*  len_mean  ; 
exp  :  begin 

message  len  ;*  abs(len_mean  *  ln(mth$random(seed))) 
message_len  :=  message_len  /  blts_per  data  word  ; 
length  :=  round(message_len)  ; 
message_len  :=  length  ; 
if  message_len  >  max_data_words 

then  message_len  :■  max_data_words 
else  if  message_len  <  min_data_words 

then  message_len  :=  mln_data_words  ; 
message  len  :*  message_len  *  bits  per  data  word  ; 
end  ; 

end  (*  of  case  *) 

I  ;  f****  calc  arr  and  len  ****) 


*  * 

*  DATE:  27  Aug  1985  * 

*  VERSION:  1.1  * 

4c  * 

*  NAME:  calc_flrst_arr_and_len  * 

*  MODULE  NUMBER:  1.3  * 

*  DESCRIPTION:  calculates  arrival  time  and  length  of  first  * 

*  messages  for  all  stations  * 

*  PASSED  VARIABLES:  none  * 

*  RETURNS:  none  * 

*  GLOBAL  VARIABLES  USED:  current_statlon  front_statlon  * 

*  GLOBAL  VARIABLES  CHANGED:  current_statlon  * 

*  FILES  READ:  none  * 

*  FILES  WRITTEN:  none  * 

*  MODULES  CALLED:  calc_arr_and_len  * 

*  CALLING  MODULES:  sel_bus_setup  * 

*  * 

*  AUTHOR:  Jim  Spleth  * 

*  HISTORY:  * 

*  1.1  27  Aug  85  added  test  for  constant  arr  rate  of  0.0* 

*  1.0  20  Aug  85  original  * 

*  * 

procedure  calc_flrst_arr_and_len  ; 


1  :  Integer  ; 

arrlval_tlme,  message_len  :  real  ; 
temp_mess  :  me8sage_type  ; 
ptr  ;  message_ptr  ; 

begin 

wrltelnC 'calc  first  arr  and  len  module') 
current  station  :<■  front  station  ; 


for  1  :■■  1  to  nuni_statlons  do 
begin 

if  ((current_station*.attrib.mes8_arr_type  <>  constant_arr)  or 
(current_statlon''.attrib.mes8_arr_rate  <>  0.0  )) 
then 
begin 

calc_arr_and_len  ( 

current_statlon"  .attrib  .ine88_arr_type , 
current_8tation" .attrib.me88_arr_rate , 
cur  rent_8 1  a  t  Ion  " .  a  1 1  r  lb .  me  8  8_len_type , 
cur ren t_8  tat Ion ".attrlb.mes  8_len_mean , 

arrival_time ,  me88age_len)  ; 

temp_mes8 . aource_add  :»  current_8tatlon".attrlb.addres8  ; 
temp_mes8. length  me8sage_len  ; 

temp_me88.arr_tlme  ;■  arrlval_tlme  ; 
new(ptr)  ; 

ptr“.info  temp_me8S  ; 
ptr '.next_mes8age  :*  nil  ; 

current_8tatlon“.attrib.front_mes8_queue  :=  ptr  ; 
current_atation".attrlb.rear_me88_queue  :*  ptr  ; 
end  ; 

current_atatlon  :*  current_statlon'".next_8tation 
end 

end  ;  (****  calc_fir8t_arr_and  len  ****) 
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^4t*4t4tA4t*A4i4c***4t4t4i*A4t4rAilt***4t*****AA4tA*A4(****A*AAA***A*****4r4tA*llt4t4;* 


* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 


DATE:  22  Aug  1985 
VERSION:  1.0 


* 
* 
* 
* 

NAME:  lnlt_8tats  * 

MODULE  NUMBER:  1.4  * 

DESCRIPTION:  initializes  the  station  statistics  linked  list* 
PASSED  VARIABLES:  none  * 

RETURNS:  nothing  * 

GLOBAL  VARIABLES  USED:  front_station  * 

GLOBAL  VARIABLES  CHANGED:  front_stats  current_stats  * 

FILES  READ:  none  * 

FILES  WRITTEN:  none  * 

MODULES  CALLED:  none  * 

CALLING  MODULES:  sel_bus_setup  * 

* 
* 
* 
* 


AUTHOR:  Jim  Spleth 
HISTORY: 


procedure  inlt_scats  ; 


var 


temp_stats  :  stats_type  ; 
ptr  :  statsjptr  ; 
j  :  Integer  ; 


begin 

writelnC 'inlt  stats  module'}  ; 
current  station  :*=  front  station  ; 


for  j  :■  I  to  numjstatlons  do 
begin 

temp  jBtats. address  :■  current_station*.attrib. address 
temp__8tats.num_acces8  :■  0.0  ; 
temp^8tats.8um_acces8  :■  0.0  ; 
temp__stats .mln_access  l.OeA  ; 
temp__8tat8 .max_access  :*  l.Oe-9  ; 
temp__stats .num_message8  :■>  0.0  ; 
temp_8tat8.suffl_ffles8_len  ;■  0.0  ; 
temp_jstats.mln_ffles8_len  1.0e6  ; 
temp__8tat8.max_mes8_lea  :>  1.0  ; 
temp_8tat8.sum_me8s_delay  :*•  0.0  ; 
temp_stats.mln_mess_delay  :*  1.0e4  ; 
temp_8tat8.max_mesa_delay  :=  l.Oe-9  ; 
new(ptr)  ; 

If  j  -  I 
then 
begin 

front_8tats  :=  ptr  ; 
current_8tata  ptr  ; 
end 
else 

current_8tats''.next  ;=  ptr  ; 
ptr''. data  temp__stat8  ; 

If  j  •  num_statlons 

then  ptr''. next  :«■  front__stats 
else  ptr next  s-  nil  ; 

current_8tatlon  current^statlon''.next_8tatlon  ; 

If  j  >  1  then  current__8tat8  :*  ptr  ; 
end  ; 

end  ;  (****  inlt  stats  ****) 


*  * 

* 


DATE:  13  Sep  1985 
VERSION:  1.1  * 

* 

NAME :  calc_token_prop_delays  * 

MODULE  NUMBER:  1.5  * 

DESCRIPTION:  calculates  token-passing  propagation  times  * 

PASSED  VARIABLES:  none  * 

RETURNS:  nothing  * 

GLOBAL  VARIABLES  USED:  £ront_station  num_8tatlons  * 

prop_factor  speed_light  * 

calc_pas8_j>rop_time 

GLOBAL  VARIABLES  CHANGED:  current_8tatlon  8ig_prop 

8lg_delay 

FILES  READ:  none 


FILES  WRITTEN:  none 

MODULES  CALLED:  none 

CALLING  MODULES:  sel_bu8_8etup 


* 
* 
* 
* 

AUTHOR:  Jim  Spleth  * 

HISTORY:  1.1  13  Sep  85  added  calc_pass_prop_time  test  * 
1.0  31  Aug  85  original  * 

* 

procedure  calc_token_prop_delays  ; 


var  distance  :  real  ; 

p,  q  :  Integer  ; 

begin 

slg_prop  :■  prop_f actor  *  speed_llght  ; 
sig_delay  :■  1.0  /  slg_prop  ; 
current_statlon  :■  front_8tatlon  ; 
if  calc_pas8_prop_tlme 
then 

for  p  :»  1  to  num_statlons  do 
begin 

distance  :=  ab8(current_8tation“.attrib. distance  - 

current_station^ .next_8tation'' .attrlb. distance  ) 
current_station''.attrlb.pass_j)rop_time  :•  distance  *  sig_delay 
wrlteln(current_8tatlon“. attrlb. address,  ’ 

current_station''.attrib.pass_prop_tlme  )  ; 
current_statlon  ;*■  current_statlon*.next_statlon  ; 
end 
else 

for  q  :■  1  to  num_stations  do 
begin 

wrlteln(current_8tation".attrib. address,  ’  ’, 

current_station''. attrlb. pass__prop_time  )  ; 
current  station  :■  current  station". next  station  ; 


(**************************************************************** 


DATE:  31  Aug  1985 
VERSION:  1.0 


NAME:  sel_bus_setup 
MODULE  NUMBER:  1.0 

DESCRIPTION:  executive  for  modules  to  setup  bus  conflg. 

PASSED  VARIABLES:  none 

RETURNS:  nothing 

GLOBAL  VARIABLES  USED:  none 

GLOBAL  VARIABLES  CHANGED:  none 

FILES  READ:  none 

FILES  WRITTEN:  none 

MODULES  CALLED:  bus_data_lnput 

statlon_data_lnput 
calc_f  Ir  s  t_arr_and_len 
lnlt_stats 

clac_token_prop_delays 
CALLING  MODULES:  busslm  (main) 


AUTHOR:  Jim  Spleth 
HISTORY: 


* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 


procedure  sel_bus_setup  ; 


begin 

wrltelnC 'select  bus  configuration  setup  module')  ; 
bus_data_lnput  ; 

8tatlon_data_lnput  ; 
calc__flrst_arr_and_len  ; 
lnlt_stats  ; 

calc  tokenprop  delays  ; 


(^h*************************************************************** 
*  * 

*  DATE:  24  Sep  1985  * 

*  VERSION:  1.4  * 

*  * 

*  TITLE:  simulate  * 

*  FILENAME:  simulate. pas  * 

*  COORDINATOR:  Jim  Spleth  * 

*  PROJECT:  Avionics  Bus  Simulation  Model  * 

*  OPERATING  SYSTEM:  VAX/VMS,  Version  4.2  on  VAX-11/782  * 

*  LANGUAGE;  Pascal  * 

*  USE:  %lnclude  file  for  program  busslm  * 

*  CONTENTS:  simulate  * 

*  calc_next_arr_and_len  * 

*  dlst_algor  * 

*  cent_algor  * 

*  FUNCTION:  performs  the  simulation  of  the  bus  * 


(It*************************************************************** 
*  * 

*  DATE:  21  Aug  1985  * 

*  VERSION:  1.0  * 

*  * 

*  NAME:  calc_next_arr_and_len  * 

*  MODULE  NUMBER:  2.1.4  * 

*  DESCRIPTION:  calculates  arrival  time  and  length  of  next  * 

*  message  for  current  station  * 

*  PASSED  VARIABLES:  none  * 

*  RETURNS:  none  * 

*  GLOBAL  VARIABLES  USED:  current_station  * 

*  GLOBAL  VARIABLES  CHANGED:  none  * 

*  FILES  READ:  none  * 

*  FILES  WRITTEN:  none  * 

*  MODULES  CALLED:  calc_arr_and_len  * 

*  CALLING  MODULES:  dist_algor  * 

*  * 

*  AUTHOR:  Jim  Spieth  * 

*  HISTORY:  * 

*  * 

procedure  calc_next_arr_and_len  ; 


arrival_time, 

message_len 

temp_mess 


:  real  ; 

:  message_type  ; 


begin 

calc_arr_and_len( 

current_station " . attrib .mess_arr_type , 
current_station''.attrib.mess_arr_rate, 
current_station''  .attrib.  mess_len_type , 
current_station''.attrib.mess_len_mean, 

arrlval_time ,  message_len)  ; 

temp_mess.source_add  :*  current_station" .attrib. address  ; 
temp_mess. length  :=  message_len  ; 
temp_mess .arr_tlme  :=  arrival_tlme  ; 

in_rear_queue( current_station''. attrib. front_mess_queue , 

current_statlon'' .attrib. rear_mess_queue ,  temp_mess) 


end  ; 


I 


*  * 

*  DATE:  24  Sep  1985  * 

*  VERSION:  1.3  * 

*  * 

*  NAME:  dist_algor  * 

*  MODULE  NUMBER:  2.1  * 

*  DESCRIPTION:  simulates  distributed  token-passing  algorithm  * 

*  PASSED  VARIABLES:  none  * 

*  RETURNS:  none  * 

*  GLOBAL  VARIABLES  USED:  slm_clock  pass__cycle  blt_rate  * 

*  current_station  current_stats  * 

*  token_blts  stat__delay  n\im_stations* 

*  token_hold_llmit  token_hold_type  * 

*  GLOBAL  VARIABLES  CHANGED:  current_8tatlon  current_stats  * 

*  FILES  READ:  none  * 

*  FILES  WRITTEN:  none  * 

*  MODULES  CALLED:  calc_next_arr_and_len  * 

*  out_f  ront_queue  * 

*  update_access_stats  * 

*  update_message_stats  * 

*  update_delay_stats  * 

*  update_thruput_stats  * 

*  CALLING  MODULES:  simulate  * 


I  ^ 


AUTHOR:  Jim  Spleth 
HISTORY: 


24  Sep  85  added  token_hold_type 

31  Aug  85  added  update_delay_3tats  call 

29  Aug  85  added  update_jacces8_stats  call 

21  Aug  85  original 


If***************************************************************} 


procedure  dlst_algor  ; 


send,  station_count , 
pass_cycle 


:  Integer  ; 


data_len,  mess_tx,  mess_len,  cycle_tlme,  sum_data_bits , 
sum_over_blts ,  hold_llmlt  :  real  ; 


begin 

wrltelnC 'dlst  algor  module')  ; 
send  :=  1  ; 

8tation_count  :=  1  ; 
pa8s_cycle  :=  1  ; 
cycle_time  :=  sim_clock  ; 
8um_data_bits  :=  0.0  ; 
8um_over_blts  :■  0.0  ; 
current_station  :*  front_statlon 
current_stat8  :••  front_stat8  ; 
hold  limit  :■  token  hold  limit  ; 


(**  send“l“yes,  send^O^no  **) 


y  > 


while  (siin_clock  <  siin_stop_time)  do 
begin 

update_access_stats(current_station''.attrib.last_access ,  pass_cycle) 
if  (current_station''.attrib.front_mess_queue  <>  nil) 
then 
begin 

while  (send  =1)  do 
begin 

if  current_station“.attrib.mess_arr_type  <>  contin  then 
if  current_s tation " . attrib . f ront_mess_queue  * . info . arr_t ime 
>  sim_clock  then  send  :>»  0  ; 
if  send  ■  1  then 
begin 
data_len 

current_station “ .attrib . f ront_mess_queue ' . info . length  ; 
mess_len  :=  data_len  +  overhead_blts  ; 
mess_tx  mess_len  /  bit_rate  ; 
case  token_hold_type  of 

time  :  if  mess_tx  >  hold^limit 
then  send  0  ; 
nxjm  ;  if  hold_liinit  *  0.0 
then  send  :*  0  ; 
end  ;  (*  of  case  *) 

if  send  *  1  then 
begin 

update_niessage^stats(mess_len)  ; 
sim_clock  ;=  sim_clock  +  ines8_tx  ; 

if  current_8tation'. attrib. mess_arr_type  <>  contin  then 
update_delay__stats( 

current_station^.attrib.front_mess^queue  .info.arr__tinie)  ; 
calc_next_arr_and_len  ; 

out_f ront_queue( current__station  ^ .attrib . f ront_mes8_queue 
current_station'',attrib.rear_mess_queue)  ; 
sum_data_bit8  :=  sum__data_bits  +  data_len  ; 
suin_over_bits  :*  sum_over_bits  +  overhead_bits  ; 
case  token_hold_type  of 


time  :  hold_limit  :*  hold_limit  -  mess_tx  ; 
num  :  hold_limit  :=  hold_limit  -  1.0  ; 
end  ;  (*  of  case  *) 

end  ; 
end  ; 

end  ;  (*  send  while  *) 

end  ;  (*  nil  if  *) 

sim_clock  :=  sim_clock  +  (token_bits  /  bit_rate)  ; 

8um_over_bits  :■  sum_over_bits  +  token_bits  ; 

sim_clock  8im_clock  +  current_s tation*. at trib.pass_prop_time  ; 

sim_clock  :■  sim_clock  +  stat_delay  ; 

current_8tation  :*  current_8tation*.next_8tation  ; 

current_8tats  :*•  current_stats'' .next  ; 

station_count  :■  8tation_count  +  1  ; 

send  1  ; 

hold  limit  token  hold  limit  : 


if  statlon_count  >  nuni_stations  then 
begin 

pass_cycle  pass_cycle  +  1  ; 
station_count  :=  1  ; 

cycle_time  ;=  sim_clock  -  cycle_time  ; 

update_thruput_stats(cycle_time,  sum_data_bits,  sum_over_bits) 
cycle_time  :=  sim_clock  ; 
end  ; 

^  whil6  ****) 

(j  j  (A***  dist  algor  ****) 


^  *******  3l:**************i>nllf  *********************  *****************K 


DATE:  24  Sep  1985 
VERSION:  2.1 

NAME :  cent_algor 
MODULE  NUMBER:  2.2 

DESCRIPTION:  simulates  centralized  token-passing  algorithm 
PASSED  VARIABLES:  none 
RETURNS:  none 
GLOBAL  VARIABLES  USED 


sim_clock  pass_cycle  bit_rate 
current_station  current_stats 
token_bits  stat_delay  num_stations* 
token_hold_limit  token_hold_type  * 
GLOBAL  VARIABLES  CHANGED:  current_station  current_stats 
FILES  READ:  none 
FILES  WRITTEN:  none 

MODULES  CALLED:  calc_next_arr_and_len 
out_f  ront_queue 
update_access_stats 
update_message_stats 
update_delay_stats 
update_thruput_stats 
CALLING  MODULES:  simulate 


AUTHOR:  Jim  Spieth 
HISTORY: 

2.1  24  Sep  85  added  token_hold_type 

2.0  17  Sep  85  simplified  (deleted  next  message  lines) 

1.0  31  Aug  85  original 


**************************************************************** ) 

procedure  cent_algor  ; 

var  send,  send_token,  pass, 

station_count ,  pass_cycle  :  integer  ; 


data_len,  mess_tx,  mess_len, 
cycle_tlme,  sum_data_blts, 
sum_over_bits ,  hold_limit  :  real  ; 

begin 

wrlteln( ' centralized  algorithm  procedure  called')  ; 

send  :=  1  ;  (**  send=l=yes,  send=0=no  **) 

send_token  :=  0  ; 

pass  :=  0  ; 

statlon_count  :=  1  ; 

pass_cycle  :=  1  ; 

cycle_tlme  :=  slm_clock  ; 

sum_data_bits  :=  0.0  ; 

sum_over_bits  :=  0,0  ; 

current_station  :=  front_statlon  ; 

current_stats  :=  front_stats  ; 

hold  limit  :=  token  hold  limit  : 


while  (sim_clock  <  sim_stop_time)  do 
begin 

update_access_stat8(current__station".attrib.last_access,  pa88_cycle  )  ; 
if  current_station" •attrib.front_mes8_queue  =  nil 
then  send_token  :*  1 
else 

while  (send  =  1)  do 
begin 

if  current_8tation'' .attrib.mess__arr_type  <>  contin 

then  if  current_station".attrib.front_me88_queue'.info.arr_tfme 
>  sim_clock 

then 

begin 

send  :=  0  ; 
if  pass  >  0 

then  send_token  :=  0 
else  send_token  :=  1 
end  ; 

if  send  =  1 
then 
begin 

data_len  : = 

current_station  .attrib .  f ront_mess_queue  “ .  info .  length  ; 
mess_len  ;=  data_len  +  overhead_bit8  ; 
mess_tx  :=  mess_len  /  blt_rate  ; 
case  token_hold_type  of 

time  :  if  mess_tx  >  hold_liinit 
then 
begin 

send  ;*  0  ; 
if  pass  >  0 

then  send_token  :■  0 
else  send_token  :=  1 
end  ; 

num  ;  if  hold_llmit  =  0.0 
then 


begin 

send  ;>■  0  ; 
if  pass  >  0 

then  8end_token 
else  8end_token 
end  : 


0 

1 


end 


(*  of  case  *) 


(*  send  message  *) 


If  send  “  1  then 
begin 

update_message_stats(iness_len)  ; 
sim_clock  :=  sim_clock  +  mess_tx  ; 

If  current_statlon'' .attrlb.mess_arr_type  <>  contln  then 
update_delay_s  ta  t s ( 

current_8tatlon“ .attrlb.front_mess_queue''  .info.arr_tlme)  ; 
calc_next_arr_and_len  ; 

out_f  ront_queue(current_8tatlon* .attrlb. f ront_mess_queue , 
current_statlon'‘ .attrib.rear__mess_queue)  ; 
8um_data_blts  :®  8um_data_blts  +  data_len  ; 
sum_over_blts  sum_over_bits  +  overheadjbits  ; 
pass  pass  +  1  ; 
case  token_hold_type  of 

time  :  hold_llmlt  :•  hold_llmlt  -  mess_tx  ; 
num  :  hold_llmlt  :*  hold_llmlt  -  1.0  ; 
end  ;  (*  of  case  *) 

end  ; 
end  ; 

end  ;  (*  send  vhlle  *) 

If  send_token  =  1 
then 
begin 

sim_clock  :*  sim_clock  +  (token_bits  /  bit_rate)  ; 
sum_over_blts  sum_over_blts  +  token_blts  ; 
end  ; 

slm_clock  ;=  slm_clock  +  current_statlon‘'.attrlb.pass_prop_tlme  ; 

8lm_clock  :=  sim_clock  +  stat_delay  ; 

current_station  :=  current_statlon''.next_statlon  ; 

current_stats  ;=  current_stats''.next  ; 

statlon_count  :=  statlon_count  +  1  ; 

send  ;=  1  ; 

send_token  :=  0  ; 

pass  ;=  0  ; 

hold_llmlt  :=  token_hold_llmlt  ; 

If  statlon_count  >  num_statlons 
then 
begin 

pass_cycle  ;=  pass_cycle  +  1  ; 
station_count  ;=  1  ; 

cycle_tlme  :*  slm_clock  -  cycle_tlme  ; 

update_thruput_stats(cycle_tlme,  s\im_data_bits ,  sum_over_bit8)  ; 
cycle_tlme  :■  slm_clock  ; 
end  ; 

end  ;  (****  while  ****) 

end  ;  (****  cent_algor  ****) 


(^it*************************************************************** 


DATE:  24  Aug  1985 
VERSION;  1.0 


NAME :  simulate 
MODULE  NUMBER:  2.0 

DESCRIPTION:  executive  for  bus  simulation 
PASSED  VARIABLES:  none 
RETURNS:  none 

GLOBAL  VARIABLES  USED:  bus_control 
GLOBAL  VARIABLES  CHANGED:  none 
FILES  READ:  none 
FILES  WRITTEN:  none 
MODULES  CALLED;  dlst_algor 
cent_algor 

CALLING  MODULES:  busslm  (main) 


AUTHOR:  Jim  Spleth 
HISTORY; 


* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 


****************************************************************•) 
procedure  simulate  ; 


begin 

vrrltelnC 'simulation  control  module  entered')  ; 
case  bus_control  of 
dlstrlb  ;  dlstjalgor  ; 
central  :  cent_algor 
end  (*  of  case  *) 


Appendix  C.  Test  Case  Command  Flies 


This  appendix  contains  the  command  flies  used  to  execute  the  seven 
test  case  simulations  In  Chapter  IV.  The  first  line  of  each  file  Is  a 
comment  Indicating  which  test  case  and  condition  the  file  was  used  for. 
For  most  of  the  test  cases,  ten  simulations  were  made  with  different 
message  arrival  rates  to  generate  data  which  was  presented  as  delay- 
throughput  curves.  However,  only  one  command  file  representing  one 
message  arrival  rate  set  Is  Included  In  this  appendix  for  each  condition 


of  each  test  case. 


!  Third  Test  Case  Worst  Case  Token-Passing  Sequence 

$  run  dlsk$user : [spleth.bu&]busslm 

480 

30  1  50.0e6 


30 

0.666666666 

1 


60.0  0.5e-6 


22.0 

0.0 

0.6 

1 

70.0 

256.0 

1 

10.0 

30 

2.0 

30 

10.0 

2 

60.0 

2 

50.0 

29 

2.5 

29 

50.0 

3 

59.0 

3 

500.0 

28 

3.0 

28 

500.0 

4 

58.0 

4 

500.0 

27 

3.5 

27 

500.0 

5 

57.0 

5 

50.0 

26 

4.0 

26 

50.0 

6 

56.0 

6 

10.0 

25 

4.5 

25 

10.0 

7 

55.0 

7 

10.0 

24 

5.0 

24 

10.0 

8 

33.0 

8 

50.0 

23 

6.0 

23 

50.0 

9 

32.0 

9 

500.0 

22 

7.0 

22 

500.0 

10 

31.0 

10 

500.0 

21 

8.0 

21 

500.0 

11 

30.0 

83.32e-6 

400.0 

64.0 


!  Fourth  Test  Case  Bit  Rate  =  25  megabits/second 

$  run  dlsk$user: [spleth.busjbusslm 

480 

30  1  25.0e6 

0.666666666  60.0  0.5e-6 

1  20  166.64e-6 


!  Fourth  Test  Case  Bit  Rate  =  40  megabits/second 

$  run  dlsk$user: [spleth.bus]busslm 

480 

30  1  40.0e6 

0.666666666  60.0  0.5e-6 

1  20  104.15e-6 


!  Fifth  Test 

Case  Maximum  Message  Length  1024  data  words 

$  run  dlsk$user : [spleth.busjbusslm 

480 

30 

1 

50.0e6 

0.666666666 

60.0 

0.5e-6 

1 

2 

0 

329.08e-6 

0 

1 

1 

400.0 

0 

1 

0 

64.0 

22.0 

70.0 

16.0 

0.0 

1024.0 

!  Fifth  Test 

Case  Maximum  Message  Length  ■*  4096  data  words 

$  run  dlsk$user: [spleth.busjbusslm 

A80 

30 

1 

50.0e6 

0.666666666 

60.0 

0.5e-6 

1 

2 

0 

1.312l20e-3 

0 

1 

1 

400.0 

0 

1 

0 

64.0 

22.0 

70.0 

16.0 

0.0 

4096.0 

!  Seventh  Test  Case  Distributed  Control  Protocol 

$  run  dlsk$user : [spleth.bus]busslm 

480 

30  1  50.0e6 

0.666666666  60.0  0.5e-6 

0  10  1.31136e-3 

0  11  400.0 

0  10  128.0 

112.0  112.0  8.0 
0.0 


1 

60.0 

1 

1 

1 

112.0 

8182.0 


1.31136e-3 

400.0 

128.0 
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